Error handling of an API is exactly the same as error handling of any web application. Exceptions should be logged to a central syslog server, and the central log should be reviewed on regular basis. If you use a framework, the framework should handle this for you.
Sending e-mails through PHP every time an exception occurs is a risky path. What if exceptions occur within the sender itself? What if SMTP server is down and you receive no e-mails for weeks? What if a hacker is intentionally generating thousands of exceptions per second?
The response code in a case of an exception should be HTTP 500 Internal Server Error. You are not expected to invent your own response codes, since the point of the API is to use a standard interface any developer can understand. If you use a framework, the framework should handle this for you.
Never claim that you tested your app so well that there are no bugs. Bugs will be found, and your company's reputation will suffer.
How client app should react to HTTP 500 depends on the application. It may inform the user that something went wrong. Or may retry. Or dispatch an AJAX request containing the error and the stack trace. Avoid popups, since they are annoying and will be dismissed most of the time. Don't ask the user to contact you: he is already annoyed by the fact that your application is not working, so you are not in a position of asking the user anything. On the other hand, apologizing and providing a contact address for support is nice.