Skip to main content
Common HTTP status codes
Status
Description
200
Everything worked as expected.
201
Everything worked as expected and a new resource was created. This is typically used for create operations (POST requests).
400
The request was unacceptable, often due to a validation error.
401
No valid credentials provided.
403
The provided credentials don't have permissions to perform the request.
404
The requested resource doesn't exist.
500
Something went wrong on our end.
The API uses HTTP status codes to indicate the success or failure of a request. Status codes in the 200-299 range indicate success, codes in the 400-499 range indicate a client error (e.g failed validation) and should be fixed and retried in your end, and codes in the 500-599 range indicate a server error on our end. Status codes in the 300-399 range indicate a redirect. Some endpoints are idempotent and so are safe to retry.

​
Error response

​
code
string
required
A machine-readable error code that can be used to programmatically handle the error.
​
detail
string
required
A developer-facing description of the error. This description is not meant to be displayed to the user.
​
docs
string
A URL to the error documentation page.
​
params
array
An array of objects describing the parameters that caused the error. This is mostly present for validation errors (HTTP 400).
​
context
object
A context object that provides additional information about the error. This is mostly present for errors that are related to the request (e.g. insufficient funds) and not a specific parameter.

​
Examples

{
    "code": "invalid_request",
    "detail": "The request is invalid.",
    "docs": "https://docs.engine.usesophic.com/api-reference/errors#invalid_request",
    "params": [
        {
            "path": "body.account_id",
            "detail": "Account not found",
            "code": "not_found"
        }
    ]
}

​
Debugging errors

In addition to error codes returned from API responses, you can inspect the response headers for a unique request ID (Request-Id). This ID is assigned as soon as the request is received and is used to identify the request in our logs. We recommend logging request IDs in your production deployments for more efficient troubleshooting with our support team, should the need arise.

​
Client request IDs

In addition to our request IDs, you can also supply your own request IDs via the Client-Request-Id header. This header is not added automatically; you must explicitly set it on the request. The format is up to you; we recommend using a UUID or your internal trace ID up to a maximum of 255 characters. We will reject any request with a Client-Request-Id header that is longer than 255 characters. If you supply a client request ID, we will log this value in our internal logs so make sure it is not leaking any sensitive information. In cases of timeouts or network issues when you can”t get the Request-Id response header, you can share the Client-Request-Id value with our support team, and we can look up whether we received the request and when.