Skip to main content

Error shape

Every error uses a standard HTTP status code and a consistent JSON envelope:
Branch your integration on the stable 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’s status moves through queuedprocessingcompleted 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 returns 429 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 a 429: 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

Set reference_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.