Troubleshooting Errors
Errors in the new standard of Core API have been improved to provide more meaningful information when you encounter errors. This document serves as a troubleshooting tool to help determine the source of any errors you might encounter.
4xx Errors
4xx errors refer to errors that begin with 4 (e.g. 400, 404, etc). If you are receiving a 4xx error, this most likely means that there is a problem in your request to the endpoint. List of 4xx errors are listed below, their meaning and how to troubleshoot them:
Error Code | Troubleshooting Tip(s) |
---|---|
400(Bad Request) | This is usually a client-side error when making the API call. Errors can be like malformed request syntax, invalid request message parameters, or deceptive request routing etc.Make sure Content-Type header is set to application/json . Refer to the errors object to determine if there is an problem with the data passed in request body |
401 (Unauthorized) | The necessary authentication credentials are not provided or are incorrect in the request header: Authorization: Bearer <your_token> More information on Authentication here. |
403 (Forbidden) | This error indicates that the request is formed correctly, but the API refuses to honour it, i.e. - the user does not have the necessary permissions to access that resource. Please review user permissions. - the resource you are trying to cannot be accessed due to it’s current state/status. |
404 (Not Found) | This error indicates that the API could not map the client’s request URI to particular endpoint/resource. This condition can be temporary or permanent. Please double check the endpoint and refer to documentation. |
405 (Method Not Allowed) | This indicates that the API request tried to use an HTTP method that the resource does not allow. - Example: Calling a POST HTTP method on a read-only resource (GET). - Please review API endpoint specification to ensure that you are using the correct endpoint and supported methods only. |
410 (Gone) | This indicates that the access to requested resource is not longer available (depreciated) and this condition is likely permanent. |
422 (Unprocessable Entity) | The request body was well-formed but contains semantic errors. A 422 error code can be returned from a variety of scenarios including, but not limited to: - Incorrectly formatted input - Checking out products that are out of stock - Canceling an order that has fulfillments - Creating an order with tax lines on both line items and the order - Creating a customer without an email or name - Creating a product without a title The response body provides details in the message parameter, as well as a specific errorCode that can be used to get more detailed explanations + fixes docs.tulip.com/integrating/aerial/errors/ |
429 (Too Many Requests) | This indicates the user has sent too many requests within a certain amount of time (“rate limiting”). |
5xx Errors
5xx errors refer to errors that begin with 5 (e.g. 500, 501, etc). When receiving a 5xx error, this usually means that a server error occurred while attempting to use an endpoint . List of 5xx errors are listed below, their meaning and how to troubleshoot them:
Error Code | Troubleshooting Tip(s) |
---|---|
500 (Internal Server Error) | This server error indicates that an internal error occurred. The API service will generate a report and the Tulip team will look into it. |
503 (Service Unavailable) | This server error indicates that the API service is not available right now. Possible causes: - Error could also be a result of user trying to retry a call before the timeout period after receiving 429 - Too Many Requests error. |
504 (Gateway Timeout) | This server error indicates that the server, did not get a response in time from the server that it needed in order to complete the request. Note: All API calls in tulip have a maximum timeout of 10 seconds. |
If the errors persists, please contact Tulip Support.