Troubleshooting

This section outlines what to do and who to call if your connections to your client services go sideways.

Don't see what you need here? Contact us!

Connection Issues

If you are having trouble connecting to the eFax Enterprise API, use the GET /health call to determine whether the Fax Services endpoint is operational and accepting traffic. This is a simple endpoint that returns a 200 (Success) code if the endpoint is operational, or a 500 (Internal Server Error) code if it is not.

If this call indicates that the system is operational, check the following for possible connection issues:

  • Be sure that the port you are using to access the API is open.
  • Check/ping your local server/environment and ensure that it is operating normally.

If the GET /health call indicates that the system is operational and yet the API Portal is down, please contact Support at [email protected].

Authentication Issues

If you cannot gain access to the API, check the following:

  • Make sure that you are using a valid API Key to build your OAuth Bearer Tokens. If needed, rebuild your token by following the Authorization procedure in the Obtaining Authentication Credentials section.
  • Tokens expire after 24 hours. Make sure that your token has not reached this limit. If it has, build a new token per the Authorization procedure.
  • Make sure that you correctly encoded your Client Key and Secret per the Authorization procedure. The string used to generate the token must be Base64 encoded.

Call/Endpoint Failures

If your calls are failing, check the following:

  • Make sure that your calls/methods are spelled correctly and that they match the nomenclature specified in the eFax Enterprise API Specification.
  • Make sure your endpoint URL is pointing correctly to your production or QA environment as needed.
  • Make sure that your fax payloads are not violating the send limitations specified in the System Characteristics section.
  • Make sure that you are passing in the required parameters in the header of each method used. For example, in the call GET /faxes/{fax_id}/metadata, you pass in your Authorization token, a transaction-id, and a unique and valid user-id:

    • The Authorization token must be constructed per the Authorization procedure.
    • The transaction-id passed in the header of the original call is a unique string used to track an API request through its lifetime. Most often this takes the form of a UUID, but the client can pass in any value. Since this header is optional, if it is not passed in the original call it is generated by the API and returned to the client.
    • The user-id must be the one issued when the user was on-boarded to the API through their Application Provider. If you are unsure of your user-id, contact your Application Provider administrator or contact Support at [email protected].

  • For all headers, make sure that you understand the expected default values and any ranges that apply. Make sure the values you are using match these limits.
  • Be sure you understand the error code returned in the call, if any. For each possible error code returned, you receive a verbose description of the problem that contains enough information to debug the problem. Check the developer_message, user_method, and more_info descriptions of the error for insight into the problem.
  • For all send transmissions, make sure that your fax payload is Base64 encrypted.
  • Make sure that you are using a valid OAuth Bearer token in the header of your calls.

Return to the top of this page.