Errors
The API reports errors in two ways, depending on where the request fails.
Request Errors
If the request is rejected before the query runs, the API returns an HTTP error status.
The API returns three kinds of 400. Only the missing-operation-name case uses an actual HTTP 400. The other two come back as HTTP 200 with 400 in extensions.status.
- Missing operation name (HTTP 400), rejected before GraphQL runs:
- Query validation error (HTTP 200), e.g. an unknown field. The query never runs, so there’s no
datakey, and graphql-ruby’s owncodeis kept:
- Bad argument during execution (HTTP 200), e.g. an invalid
sortField:
There are two 401 responses. Both use HTTP 401 and come back before GraphQL runs.
- A missing, invalid or inactive API key:
- A valid key whose account is disabled or no longer has app access:
A rate-limited request gets an HTTP 429. It carries the two rate-limit headers, with Remaining at 0, and a Retry-After header with the number of seconds until the limit resets:
Include the request_id when you contact Tradespace support about a failed request.
GraphQL Errors
Once the query runs, the response is 200 OK even when part of it fails. Failures appear in the errors array. Each error’s extensions.status holds an HTTP-style status. A failing field that can be null resolves to null. Single-record queries such as disclosure or patent cannot be null, so when one of them fails the whole data value is null.
If you’re getting 500 errors, check status.tradespace.io for outages.
400 invalid argument value:
403 feature not enabled or not authorized:
404 record not found:
500 server-side failure (e.g. a non-null field resolved to null):
Always check errors before reading data.