Response Codes

Interpret HTTP status codes returned by the Samsara API and learn how to handle 2XX, 4XX, and 5XX responses.

All API requests will respond with an appropriate HTTP status code.

Your API client should handle each response class differently:

• 2XX codes are successful responses.
• 4XX codes are client error responses, meaning there was an error with the way the request was submitted, such as a missing parameter or invalid value. You should modify requests before retrying.
• 5XX codes are server error responses. There may be a temporary issue on the Samsara side, so you may want to retry after some delay. Please use exponential backoff as a retry model — see here for an example algorithm.

Error Codes

Here is a table of error codes that may help you debug. The error response body may include an error message, but do not hard-code against this message. We reserve the right to change the error message without auto-incrementing the API version. Only use error messages for debugging purposes.

Status Code	Description
400	Bad Request — General client error, possibly malformed data. Here are some common error messages you might see: "Configuration limit exceeded": this means that you can no longer create more of an object (e.g. users, drivers, documents) via API due to system limits. Reach out to Support to request increases.
401	Unauthenticated — The API key is missing or invalid.
403	Permission Denied — Do not have access to the requested resource. Please consult Required Licenses for API and Webhooks Usage for more.
404	Not Found — The API endpoint is invalid or a path parameter is missing or invalid (e.g. id in /fleet/drivers/{id}).
405	Method Not Allowed — The API endpoint does not accept that HTTP method.
429	Too Many Requests — The client has reached or exceeded a rate limit, a usage limit, or the server is overloaded. See Rate Limits for suggestions on retry patterns.
5XX	Internal Server errors — something went wrong with Samsara’s servers. These responses are likely momentary errors (e.g., temporary unavailability), and as a result, requests should be retried using exponential backoff. Note that the body of these responses will be strings and not JSON encoded.