One pattern I like for handling internal API errors is:

• Log the error with all the data which could be useful for analyzing it in a database or logfile
• Give that entry a GUID under which it can be found
• Include that GUID in the error message sent through the API

That way anyone who is authorized to read the local error database can take the GUID from the error message and look up what really went wrong. And you also got data about errors which you can analyze retroactively. This allows you to monitor your application, notice when the error rate goes up before the end-users complaints reach you and often even find the cause for those errors before an end-user provides you with the proper steps to reproduce the problem.

One pattern I like for handling internal API errors is:

• Log the error with all the data which could be useful for analyzing it in a database or logfile
• Give that entry a unique ID under which it can be found. Like a GUID, for example. But when you expect users to read them to you over the phone you might want to opt for something shorter. I would not recommend to use sequential numbers, because that might leak information and might have synchronization issues if your API is distributed on multiple hosts.
• Include that ID in the error message sent through the API

That way anyone who is authorized to read the local error database can take the ID from the error message and look up what really went wrong. And you also got data about errors which you can analyze retroactively. This allows you to monitor your application, notice when the error rate goes up before the end-users complaints reach you and often even find the cause for those errors before an end-user provides you with the proper steps to reproduce the problem.