Concepts

A five-minute orientation to the objects and terms that appear throughout the API.

Accounts

An account is the primary identity ClaimRev assigns to a customer — a 5-character AccountNumber (e.g. DEMO1) that follows them through every system. Every API call scopes to an account.

Credentials and accounts. While the platform technically allows a single API client id to be granted access to multiple accounts, the recommended pattern is one client id per account. If you're an EMR or billing service onboarding 100 practices, that's 100 client ids. This keeps audit trails clean and access boundaries explicit.

Parent/child accounts exist for billing and organizational rollups (e.g., a billing service that wants a single invoice across many child practices) but they don't change how API calls are made — every request still scopes to a single child AccountNumber.

Claims

A claim is a request for payment from a provider to a payer for services rendered. ClaimRev supports US X12 EDI 837 claim formats:

• 837P — professional (doctor visits, procedures)
• 837I — institutional (hospitals, facilities)
• 837D — dental

You can submit claims two ways:

Path	Formats	Endpoint
Raw EDI upload	837P, 837I, 837D	POST /api/InputFile/v1
JSON → EDI translation	837P only	POST /api/SharpRcm/v1/CreateClaimEdi

The JSON path builds the 837 internally and returns the BHT, group, and transaction control numbers it stamped on your behalf — useful for EMRs that don't want to generate EDI directly. The EDI path is the most-used and supports all three claim types; in that case you generate the control numbers yourself.

Inbound EDI Replay

The same POST /api/InputFile/v1 endpoint also accepts raw 835 files. Uploading an 835 makes ClaimRev treat it as if the payer sent it: it flows through the normal parsing pipeline, gets matched to claims, and feeds analytics and ERA reports. Useful for backfilling historical remits or testing reconciliation flows.

Only 837 and 835 are supported through this endpoint. Other transaction types (999, 277CA, 270, 271, etc.) are not currently accepted as direct uploads.

Payers

A payer is an insurance company or other entity that reimburses claims. ClaimRev maintains a global master payer list that every account uses — you don't manage payers per account.

If a specific account needs to override how a particular payer is identified or routed (for example, the source EMR sends a payer id that needs to map to a different ClaimRev payer), the account can submit a payer override. Overrides resolve to the master payer; they don't replace it.

ERAs (835s)

An ERA (Electronic Remittance Advice) is the payer's response to a claim, delivered as an X12 835. ERAs tell you whether a claim was paid, denied, or adjusted, and why.

ClaimRev parses 835s into structured JSON that you can search, fetch by id, or break down by service line:

• POST /api/PaymentAdvice/v1/SearchPaymentAdvice — list payment advice headers
• GET /api/PaymentAdvice/v1/GetPaymentAdviceById — fetch one ERA's full payment data
• POST /api/EraQuickReports/v1/GetClaimList and related reports — aggregated views, CSVs, PDFs

Raw 835 download is available through a legacy API on request — contact us if your integration needs the original EDI bytes. Self-serve raw 835 retrieval through the public API is on the roadmap.

Secondary Claims (COB)

When a patient has both primary and secondary insurance, the primary payer adjudicates first. The secondary payer then needs to know what the primary did — paid amounts, contractual adjustments, copays, deductibles — to coordinate benefits.

Once a primary claim is matched to its 835 ERA, ClaimRev can build a derived secondary claim from that combination — carrying the primary's adjudication data forward automatically so you don't have to assemble it from scratch. See Retrieving ERAs → Secondary Claim Creation for the workflow.

Eligibility (270/271)

Run a real-time eligibility check (X12 270 → 271 under the hood) by posting patient + payer info as JSON:

POST /api/SharpRevenue/v1/RunSharpRevenue (with productsToRun: [1])

The 271 result is returned synchronously in the response body — no polling required, and the response includes both the parsed structured data and the raw 271 EDI. The response also returns a claimRevResultsId so you can re-fetch the same result later via GET /api/SharpRevenue/v1/GetEligibility?sharpRevenueRtEligibilityObjectId={id}.

No prior patient setup is required: patient demographics, the practice NPI, and the subscriber's payer + member id are all passed inline.

If you already have a raw 270 X12 in hand, you can post the bytes directly:

POST /api/SharpRevenue/v1/PostEligibilityRequestFile

ClaimRev parses the 270 into JSON and runs the same pipeline.

The RunSharpRevenue endpoint also supports Demographics (product 2), Coverage Discovery (3), and MBI Finder (5) — see the SharpRevenue Tools guide for details.

Claim Status — Two Different Things

There are two ways to ask "what's happening with my claim," and they serve different purposes.

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

POST /api/ClaimView/v1/SearchClaimsPaged

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 "lost" it. A 276 ping against the payer tells you whether they have your claim, what status it's in, or that it never landed:

POST /api/SharpRevenue/v1/RunClaimStatusRequest

The result returns synchronously and includes both the parsed JSON and the raw 277 EDI. If you have an existing claim object id you want to ping, use GET /api/SharpRevenue/v1/RequestClaimStatusFromClaim instead.

The 276 EDI submission form is not currently accepted — JSON request only.

Authentication

Every API request requires a bearer token issued to your client id. See the Authentication page for the full flow. As noted under Accounts, the conventional pattern is one client id per account.