Error and Response Codes
Understanding the response codes returned by the Gratero API is essential for effective error handling and debugging. Below is a list of the common HTTP status codes you may encounter when interacting with the Gratero API.
| Code | Status | Description |
|---|---|---|
| 200 | OK | The request was successful, and the server returned the requested data. |
| 201 | Created | The request was successful, and a new resource was created. This is typically returned after creating a new shipment. |
| 400 | Bad Request | The server could not understand the request due to invalid syntax. This may occur if the request body is malformed or missing required parameters. |
| 401 | Unauthorized | Authentication failed or the API key is missing. Ensure that you include a valid API key in the header. |
| 403 | Forbidden | The server understood the request but refuses to authorize it. This can happen if you do not have the necessary permissions to access the resource. |
| 409 | Conflict | The request could not be processed because of a conflict with the current state of the resource. This typically occurs if the user has not verified their KYC details. |
| 422 | Unprocessable Entity | The server understands the content type of the request entity, and the syntax of the request entity is correct, but balance in your wallet is insufficient to process this request. |
| 429 | Too Many Requests | The client has sent too many requests in a given amount of time. Slow down your request rate and try again later. |
| 500 | Internal Server Error | The server encountered an internal error and was unable to complete your request. This is a generic error message and often indicates a problem with the server. |
Handling Errors
When you receive an error response from the Gratero API, it is important to handle it gracefully in your application. Here are some general tips:
- Check the Response Code: Use the response code to determine the type of error and take appropriate action.
- Log the Error: Log the error details for debugging purposes.
- Retry Mechanism: Implement a retry mechanism for transient errors like
500 Internal Server Erroror429 Too Many Requests. - User Feedback: Provide meaningful feedback to the user if an error occurs, so they understand what went wrong and how to correct it.