Skip to main content
GET
List claims

Authorizations

Authorization
string
header
required

Marketplace API key

Headers

X-Organization-Id
string
required

Target clinic organization ID

Query Parameters

dateFrom
string

Filter from date (ISO 8601)

Example:

"2025-01-01"

dateTo
string

Filter to date (ISO 8601)

Example:

"2025-12-31"

billId
string

Filter by bill ID

status
string

Filter by normalized claim status (comma-separated). Values: draft, submitted, invalid, rejected, denied, approved_partially, completed, unknown, ready_for_postage, worked, on_hold, scrub_failure. Supplying the parameter with NO values — ?status= or ?status=, — is a 400, not an empty filter: omit the parameter when you have no statuses to filter on.

Example:

"completed,denied"

code
string

Filter to claims whose BILL carries a line item with any of these procedure codes (CPT/HCPCS, comma-separated). THE BILL'S CODES, not the claim's own: a claim can carry a claim-scoped coding group whose line items disagree with the bill's, and this filter deliberately reads the bill, with the same scoping /v4/bills uses. A consumer joining dose -> bill -> claim wants this reading; filtering on the claim's own codes instead would drop exactly the bill/claim divergence cases such a consumer needs to see. The response cannot tell you which reading you got, which is why it is stated here. Archived bills are excluded, matching /v4/bills, so a claim whose bill was voided does not satisfy this filter — it would otherwise be a claim you cannot reconcile against any bill this API will return. NOT COVERED BY THE updatedSince CURSOR — do not combine the two for delta sync. This filter is evaluated against BILL-side rows, and the cursor is the CLAIM's own updatedAt, which does not move when a bill's coding changes. A claim whose bill gains this procedure code AFTER your cursor passed it is never delivered on any later page: it satisfies the filter, but its updatedAt stays below every subsequent cursor, and a claim in a final state is not re-synced. The reverse is as bad for a delete-by-exclusion consumer — remove the code from the bill and the claim simply stops appearing, with no tombstone to distinguish that from 'nothing changed'. Use code for full or date-windowed re-walks, which re-cover their ground, and walk updatedSince unfiltered. Exact match, case-insensitive on both the value you send and the code as stored. Supplying the parameter with NO values — ?code= or ?code=, — is a 400, not an empty filter: build the query string so an empty cohort OMITS the parameter, because silently dropping it would return every claim in the organization for a request that asked for a few.

Example:

"J3245,J0717"

integrationStatus
string

Filter by integration status

updatedSince
string

Only return claims whose record was created or modified at/after this timestamp (ISO 8601). A status change re-touches updatedAt even when the date of service does not move. When set, results are ordered by updatedAt ascending so pages are monotonic: page through to the end, then use the LAST row's updatedAt as the next cursor. Do not advance the cursor mid-pagination.Rows sharing the boundary updatedAt can re-deliver on the next pull, since the bound is inclusive — dedupe on id.

Example:

"2025-06-01T00:00:00.000Z"

updatedUntil
string

Only return claims whose record was last modified at/before this timestamp (ISO 8601).

Example:

"2025-06-30T23:59:59.999Z"

Response

Success

code
string
required

Response code

Example:

"success"

data
object
required