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]
NOTE
Not all fields and error codes have been populated at this current time, but we are working on it š
| Attributes | Description |
|---|---|
titlestring | A 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. |
statusnumber | The HTTP status code generated by our server for this occurrence of the problem. |
detailstring | A longer human-readable explanation with the full error details. |
instancestring | A 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) |
dataMap<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 Code | Status Summary |
|---|---|
200 OK | Everything worked as expected. |
201 Created | The request has succeeded and has led to the creation of a resource. |
204 No Content | Everything worked as expected. The response body is empty. |
400 Bad Request | The request was unacceptable, often due to missing a required parameter. |
401 Unauthorized | No valid API key provided. |
402 Request Failed | The parameters were valid but the request failed. |
404 Not Found | The requested resource doesn't exist. |
422 Unprocessable Entity | The request payload is incorrectly formed. |
500 Server Error | Something went wrong on Defacto's end. |