In the event that your API request doesn't work, you will receive an HTTP error response which format is a subset of the RFC 7807 standard. By utilizing this standard we have consistent identifiers to recognize types of errors, clear descriptions and metadata easily available.


Something not as expected?

If you receive an incorrect error response or don't receive one as you expect, please get in contact with our team at [email protected]



Not all fields and error codes have been populated at this current time, but we are working on it 😊

titlestringA short, human-readable summary of the error. This is explicitly advisory and you should use type as the primary way to recognize types of API error.
statusnumberThe HTTP status code generated by our server for this occurrence of the problem.
detailstringA longer human-readable explanation with the full error details.
instancestringA URI that identifies the specific failure instance.
invalid_params Array<{"name": "string", "reason": "string"}>A list of the errors found in the request payload (populated for 422 responses)
Map<Any, Any>
Additional information that may help you manually debug what happened.
This has not been standardized yet, so we don't recommend building logic on this.
HTTP Status CodeStatus Summary
200 OKEverything worked as expected.
201 CreatedThe request has succeeded and has led to the creation of a resource.
204 No ContentEverything worked as expected. The response body is empty.
400 Bad RequestThe request was unacceptable, often due to missing a required parameter.
401 UnauthorizedNo valid API key provided.
402 Request FailedThe parameters were valid but the request failed.
404 Not FoundThe requested resource doesn't exist.
422 Unprocessable EntityThe request payload is incorrectly formed.
500 Server ErrorSomething went wrong on Defacto's end.