Skip to main content

Pagination

List endpoints take two query parameters and return a consistent envelope:
All four fields are always present. Page until offset + items.length >= totalCount. Both SDKs auto-paginate internally - their list-style methods return the complete array.

Error envelope

Errors raised by the API carry a consistent JSON body:
details appears only on field-level validation failures (400, errorCode: "VALIDATION_ERROR").

Error codes

Branch on errorCode rather than parsing message - messages may be reworded, codes are contract. The ones you’re most likely to handle: New codes may be added over time - treat an unrecognized errorCode as a generic failure of its HTTP status rather than erroring out.
Rejections that happen before your request reaches the API - an invalid or missing credential (401) and unmatched routes (404) - currently return an empty body. Don’t parse the body to detect auth failure; branch on the status code, and use the x-request-id response header (returned on every request) when contacting support.
POST /v1/tools/{toolSlug}/execute is special: tool-runtime failures (the downstream API errored) return 200 with isSuccess: false and an errorMessage - not the error envelope. Branch on isSuccess, not just the HTTP status.

Rate limits

Limits are enforced per account with two budgets that must both pass: a per-second burst and a sustained hourly window. Search-backed discovery calls (GET /v1/tools or GET /v1/applications with a non-empty ?search=) have their own, stricter budget because they trigger semantic search. On 429, honor the Retry-After response header (seconds): 1 when the burst window tripped, 3600 when the hourly window tripped. Back off and retry - don’t hammer.