Port 443 is the default port for HTTPS communication using SSL/TLS. As such, if you can reject and/or redirect traffic on port 80 (the default unsecured HTTP port) and reject all other ports, and if you can trust your web server OS's TCP/IP and TLS implementations, this scheme is as safe as any publicly-accessible computer communications endpoint can be made, from a hardware/firmware perspective.
However, this only proves that the means of communication is secure, and that this comm channel is the only way to get in. That can still mean the application communicating over this channel has vulnerabilities. Someone could hijack the remote system and use the secure channel to request information the person normally wouldn't be able to get. The remote system itself could store information it retrieves from you in an insecure manner. The component of this solution residing on your webservice could be vulnerable to any number of attack vectors that don't require breaking TLS itself; a third party could, for instance, perform a replay attack to corrupt data by making your server do things twice. Or, they could properly negotiate a TLS connection with your server and then pound on the relatively weak authentication system provided by the application.
In short, just because you can expose only port 443 to the world and accept only properly-negotiated TLS connections through it does not necessarily mean your system is secure. You must also trust that the application using the TLS channel is properly implemented to prevent various attacks carried out by systems using the channel. If you cannot trust this application, you should not use it.