The pattern
CallGET /v1/claims every 1 to 5 minutes with updated_since. Don’t poll claims one by one.
- Start from the latest
updated_atyou have processed, minus about one minute. On the very first poll, leaveupdated_sinceout to read every claim you have sent. - Follow
next_cursoruntil it isnull, sending the same filters with each cursor. - De-duplicate by
id. The overlap means some claims come back more than once; that is expected and makes sure you never miss a change. - Save the newest
updated_atyou saw for the next poll.
What updated_since covers
- It is inclusive: a claim updated exactly at
updated_sinceis returned. - Results are ordered by
updated_at, thenid. updated_atmoves only when something you can see changes: the claim is created, offered to another adjuster, accepted or rejected. The adjuster’s work on the claim in the app doesn’t move it, so polls stay small.
Reading the result
Each claim’sassignment describes the latest offer:
On a rejected claim,
assignment.adjuster_osa_id is the adjuster who rejected it, responded_at is when, and rejection_reason is their optional reason. On an unassigned claim, adjuster_osa_id is null. When you offer the claim to someone else, assignment switches to the new offer.
Nothing you do through the API leaves a claim unassigned; the status is there for a claim OSA has taken back from its adjuster. Handle it the way you handle rejected.
The API reports a claim up to its acceptance. What the adjuster does afterwards (the inspection, the estimate, closing the claim) is not reported through the API today, so don’t wait for a further status.
Statuses are an open enum: handle values you don’t recognise without failing.
Other filters
assignment_status=rejected: only claims waiting to be re-offered.external_id=CMS-884512: look up a claim by your own id. A live key can get two results, a live claim and a test claim with the sameexternal_id;testtells them apart.limit: 50 by default, up to 200.