Errors & rate limits

Respond to the status

• 200 — the requested representation is returned.
• 400 — invalid parameters, unsupported fields, or an expired cursor; correct the request.
• 401 — missing, expired, or invalid credential; resolve authentication.
• 403 — the verified credential lacks the required scope.
• 404 — the resource is absent or outside the authorized boundary.
• 429 — the request budget was reached; wait for Retry-After.
• 503 — the service is unavailable; use bounded backoff for read requests.

A small, safe error envelope

The error shape is the same across resources. Use code for program logic and request_id for support correlation. Messages are fixed descriptions, not raw exceptions or echoed personal data.

{
  "code": "invalid_parameters",
  "message": "Check the request parameters.",
  "request_id": "req_example_a4d8"
}

Budget and retry behavior

No live API throughput allowance is advertised by this portal. Limits must be established for a provisioned integration. On 429, honor Retry-After as either seconds or an HTTP date; do not rotate credentials to bypass the budget.

For transient network failures and 503 responses, retry GET requests using exponential backoff with jitter and a finite attempt limit. Cache only within the authorized carrier context. Never retry a 400 or 403 unchanged.

Share identifiers, not sensitive records

When discussing an integration issue, provide the endpoint path, response status, request identifier, and approximate time. Keep tokens, full operational records, and personal data out of the inquiry. Use the website contact form for integration questions.