Poll project status
GET /v1/projects/{id} is the only status endpoint. Scope: verify:read.
Use the project UUID from create (id). Do not poll with a numeric id.
curl -s https://api.arbitr.ai/v1/projects/3f2a9c1e-4b7d-4c8a-9f10-2d6e5b7c8a91 \
-H "X-API-Key: abr_live_…"
This is also the only call that returns assessment (and a populated review when a human stage is in play). Create and list carry both as null.
What to read
| Field | Use |
|---|---|
status |
Whether to keep polling, download, or resume |
assessment.billable_character_count |
Billable source characters (basis for intelligence credits) |
assessment.due_date |
Your date, echoed unchanged |
assessment.due_date_feasible |
true / false, or null if you sent no due_date |
assessment.credits.intelligence |
required, available, sufficient — always present |
assessment.credits.trust |
Same shape when the workflow has a human stage; otherwise null |
review.status |
Human-stage lifecycle; null until a review is requested. Test this, not review |
There is no server-computed delivery date on this response.
When to stop polling
Project lifecycle is the canonical rule and carries the loop. In short: download on completed and published, stop on failed, cancelled and refunded, and read review.status before you act on status — a human stage that stalled or was cancelled leaves status reading delivered when it is not.
Honor rate limits. Sleep a few seconds between calls. Tight loops will hit 429. Always set a deadline.
Common failures
| Status | Typical cause |
|---|---|
401 / 403 |
Missing key, or key lacks verify:read |
404 not_found |
Unknown UUID, or not in your org |
Next
Download deliverables once the project is delivered.