Error shape
Every error uses a standard HTTP status code and a consistent JSON envelope:error.code (a closed, documented set),
not on the HTTP status alone (several distinct conditions can share a status)
and never on the human-readable error.message (it is advisory and may change).
Error codes
Review lifecycle & the failure contract
A review’sstatus moves through queued → processing → completed or failed. Both completed and failed are terminal; stop polling once you see either.
GET /reviews/{review_id}/report uses the status code to tell you what to do, so a failure is never mistaken for “still processing”:
Always confirm terminal state via
GET /reviews/{review_id} (status is completed or failed) rather than inferring it from the report endpoint alone.
Rate limits
Requests are rate-limited per organization (the default ceiling is 60 requests/minute, enforced across our fleet). Exceeding it returns429 Too Many Requests.
Response headers
Every rate-limited response carries the standard rate-limit headers so you can observe your remaining budget without waiting for a429:
On a
429, honor Retry-After if present; otherwise retry with
exponential backoff (e.g. 1s, 2s, 4s, … with jitter) rather than
tight-looping. Watching X-RateLimit-Remaining lets you pace requests and
avoid a 429 entirely. Webhooks let you avoid polling altogether and stay well
under any limit. If your integration needs a higher ceiling, contact your
Flightline representative.
Idempotency
Setreference_id to your own external identifier for the loan package.
Creating a second review with a reference_id that already exists returns
409, so retries won’t create duplicate reviews.