The failure that is not an error
Read this before the status code table, because it is the problem most integrations hit first. A filter value the market does not recognise does not return an error. It returns200 with an
empty result, exactly as a valid filter matching no companies would.
/filters
before assuming the data is missing.
Status codes
Response shape
Errors come from one of two places, and the difference shows up in thecontent-type.
Rejected at the gateway
Requests that never reach the data service are answered by the gateway:401, 429, and the 404
you get from an unknown path, an unknown market code or a wrong HTTP method. These carry
content-type: application/problem+json and include a trace object:
Returned by the data service
A request that routes correctly but the service cannot fulfil returns400, 422, 500, or a
404 for a company number that does not exist. These carry content-type: application/json and the
same problem-details fields, without the trace object:
Individual fields can be absent. Read
status from the HTTP response rather than the body.
500 responses may have no body at all. Do not assume an error response is parseable JSON —
check the status code first, then the content type.Reporting a problem
When contacting support@thedatacity.com, include thetrace.requestId if the response had one, or the timestamp and full request path if it did not.
That identifier lets us find the exact request in our logs.
Do not send us your API key.
Handling errors in code
Treat429 and 500 as retryable, and everything else in the 4xx range as a request you need to
fix:
detail field is written for developers, not end users. Its wording can change between
releases, so log it rather than displaying it in your own interface.