Checking Claim Status

There are three layers of "what's happening" you might want to query:

1. File-level — was the file you submitted parsed cleanly, and did the 999/277CA acks come back? See Submitting a Claim → Step 2: confirm the file landed — InputFile/GetFileList is your tool here.
2. Claim-level — what's happening with an individual claim now that ClaimRev has it? Use claim search, below. This is where most integrations spend their time.
3. Real-time payer ping — for claims that were accepted but never came back with an ERA, ping the payer directly (X12 276/277). Also below.

Routine status: claim search

Most of the time, you don't need a separate API call. When ClaimRev receives a 999 (functional ack), 277CA (claim acknowledgment), or 835 (ERA) from the payer, that data is stitched onto the claim record automatically. Claim search returns errors, acceptance status, and adjudication outcomes already on file.

POST /api/ClaimView/v1/SearchClaimsPaged
Authorization: Bearer <token>
Content-Type: application/json

The request body is a ClaimSearchModel. The most common fields you'll search on:

Field	What you'd put here
pagingSearch	Paging info (page index, page size, sort) — required to keep responses bounded
traceNumber / traceNumbers	The ISA13 control number from your submitted envelope
patientControlNumber / patientControlNumbers	The CLM01 patient control number you stamped on the claim
payerControlNumber / payerControlNumbers	The payer's reference number, if you have it
inputFileObjectId	Object id of the input file the claim came in on
patientFirstName / patientLastName / patientBirthDate	Patient demographics
serviceDateStart / serviceDateEnd	Service date range
payerNumber / payerName	Payer scoping
statusIds / excludeStatusIds	Status filters

For a CSV export of the same search, use POST /api/ClaimView/v1/SearchClaimsCsv.

The response includes whatever ClaimRev currently knows about each matching claim — error messages from validation, acceptance status from the 277CA, payment information from the 835 — paged according to your pagingSearch request. The full response shape is in the API Reference.

Real-time status: 276/277 escape hatch

Real-time claim status (X12 276/277) is the escape hatch for claims that were accepted by the payer but never came back with an ERA — i.e., the payer effectively "lost" your claim. A 276 ping against the payer tells you whether they have it, what status it's in, or that it never landed.

In practice, when payers lose claims, the only way to know is to ask them directly. Routine claim searches will only show you what acks/ERAs ClaimRev has already received — they can't surface the absence of a response.

POST /api/SharpRevenue/v1/RunClaimStatusRequest
Authorization: Bearer <token>
Content-Type: application/json

If you have an existing claim object id you want to ping, use the lookup variant instead:

GET /api/SharpRevenue/v1/RequestClaimStatusFromClaim?claimObjectId={id}
Authorization: Bearer <token>

The result returns synchronously and includes both the parsed structured fields and the raw 277 EDI the payer responded with — no separate translation step needed.

The 276 EDI submission form is not currently accepted; this is a JSON-request-only endpoint.

Choosing the right path

Question	Use…
What's the latest state of my claim per ClaimRev's records?	Claim search (SearchClaimsPaged)
Were there validation errors on submission?	Claim search
Did the payer ack it (999/277CA)? Did they pay it (835)?	Claim search
It's been weeks and there's no ERA — does the payer even have my claim?	Real-time 276 (RunClaimStatusRequest)
I want a definitive "yes/no — does this payer have this claim right now?"	Real-time 276

Searching previously-run RT status checks

Once you've run a real-time check, the result is stored. You can search past 276/277 results without re-pinging the payer:

POST /api/SharpRevenue/v1/SearchClaimStatusRequests
Authorization: Bearer <token>

This is useful for building UIs that show the history of "we asked the payer X times" alongside the claim record.