Errors and rate limits
Understand limits, retries, error codes, and production integration best practices.
Understand limits, retries, error codes, and production integration best practices.
Documentation boundary
API pages describe request patterns, endpoint groups, auth boundaries, idempotency, webhooks, errors, rate limits, and status lifecycles. Product access, environment, entitlement, and review status decide what a partner can call in production.
What this page covers
- Errors and rate limits
- Auth, idempotency, webhook, error, and retry behavior
- Status codes, errors, webhook events, and retry boundaries
How it fits
API pages describe request patterns, endpoint groups, auth boundaries, idempotency, webhooks, errors, rate limits, and status lifecycles. Product access, environment, entitlement, and review status decide what a partner can call in production.
Workflow
- Choose the product surface and environment.
- Keep secret keys on the server and use publishable keys only where explicitly allowed.
- Send documented JSON fields and include idempotency keys on writes.
- Branch on status codes and machine-readable error codes.
- Log request ids and object ids so API, webhook, scan, and operations records can be joined.
Status and data signals
| Signal | Use it for | Do not use it for |
|---|---|---|
| Request id | Trace API calls through support and logs. | Secrets or PII. |
| Error code | Stable machine-readable branch condition. | Human message parsing. |
| Webhook delivery | Asynchronous backend status. | Unsigned callback state. |
| Generated operation page | Endpoint shape where available. | General availability promise. |
Implementation notes
- Start in sandbox or test mode with fake data.
- Keep server-only credentials, webhook secrets, PII, provider payloads, and internal runbooks out of public docs and browser code.
- Use documented ids, request ids, event ids, timestamps, status fields, asset symbols, and environment names for support and reconciliation.
- Treat browser callbacks as user-experience signals; use signed webhooks, API reads, scan records, or settlement reports for durable backend state.
- Confirm product access, entitlement, regional availability, and review status before presenting the workflow as live.
Related pages
API reference
Use the API overview for endpoint groups, auth, errors, and webhooks.
Authentication
Review credential types, server boundaries, and request authentication.
Idempotency
Review setup details before building in sandbox or live mode.
Errors and rate limits
Handle retries, limits, and API errors safely.
Example trace
A useful API trace includes the environment, endpoint group, request id, idempotency key for writes, product object id, status code, machine-readable error code if present, and any resulting webhook event id. With those fields, a developer can determine whether the request failed before creation, created a pending object, completed asynchronously, or needs reconciliation. Avoid retrying with a new idempotency key until you know whether the original write created state.