Submitting a Claim

There are two ways to submit a claim through the ClaimRev API. Pick the one that fits the system you're integrating from.

Path	Claim types	Endpoint	Use when…
Raw EDI upload	837P, 837I, 837D	POST /api/InputFile/v1	Your system already generates X12 837 EDI.
JSON → EDI translation	837P only	POST /api/SharpRcm/v1/CreateClaimEdi	Your system has structured claim data and you'd rather not generate EDI yourself.

Both paths feed the same downstream processing pipeline; the JSON path simply runs the bytes through ClaimRev's EDI builder before handing off.

Path A — Raw EDI upload

Wrap your 837 file content in a JSON envelope and POST it. The endpoint accepts the EDI text either as a plain string or as base64 — choose whichever your client makes easier:

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

{
  "ediFileContent": "ISA*00*          *00*          *ZZ*SUBMITTERID    *...",
  "fileName": "claims_20260427.txt"
}

(If you'd rather send base64, use base64EdiFileContent instead of ediFileContent.)

The response confirms whether the file landed:

{
  "message": "File uploaded successfully.",
  "isError": false
}

What's accepted. The same endpoint accepts raw 837 (P/I/D) and raw 835. Other transaction types (999, 277CA, 270, 271) are not accepted as direct uploads.

Step 2: confirm the file landed

The submission response doesn't include a server-issued file id. To find your uploaded file (and check its parsing/ack status), search the input-file list:

POST /api/InputFile/v1/GetFileList
Authorization: Bearer <token>
Content-Type: application/json

{
  "fileName": "claims_20260427.txt",
  "receiveStartDate": "2026-04-27T00:00:00Z"
}

The response is a list of CustomerInputFileViewModel rows:

[
  {
    "id": "65e2f4...",
    "fileName": "claims_20260427.txt",
    "receiveDate": "2026-04-27T14:32:10Z",
    "userEmailAddress": "you@example.com",
    "accountNumber": "DEMO1",
    "fileStatusName": "Processed",
    "ackStatusName": "Accepted",
    "claimAckStatusName": "Accepted",
    "claimCount": 12,
    "exceptionMessage": null
  }
]

Field	What it tells you
id	Server-side file id. Use it as inputFileObjectId when searching claims.
fileStatusName	File-level processing status (was the EDI parsed cleanly?).
ackStatusName	999 functional acknowledgment status from the clearinghouse.
claimAckStatusName	277CA claim-level acknowledgment status from the payer.
claimCount	How many claims ClaimRev parsed out of the file.
exceptionMessage	Populated when parsing or processing failed.

The 999 functional ack arrives quickly — it's generated by ClaimRev's processing system once your file has been parsed. The 277CA claim acknowledgment arrives later (typically the day after submission). Adjudication outcomes (the 835) take days to weeks.

Use this endpoint to confirm the file was accepted and watch its ack progression; use claim search to track the individual claims afterwards.

Tracking individual claims. Because you wrote the EDI, you already know the control numbers you stamped — the ISA13 in your envelope, and CLM01 (patient control number) on each claim. Search for individual claims by those numbers, by patient demographics, or by the id you got from GetFileList (passed as inputFileObjectId).

Path B — JSON → EDI translation (professional only)

If your system has structured claim data (a clinical encounter, a charge capture, a Healthie appointment), you can hand it to ClaimRev as JSON and let ClaimRev build and submit the 837P:

POST /api/SharpRcm/v1/CreateClaimEdi
Authorization: Bearer <token>
Content-Type: application/json

The request body is a ClaimEdiCreationViewModel:

{
  "claims": [ /* array of FullClaimEditorViewModel */ ],
  "envelop": { /* IsaSegment — ISA control envelope */ },
  "submitterId": "ClmRevEdiBuilder",
  "submitterName": "...",
  "submitterContactName": "...",
  "submitterPhone": "...",
  "receiverName": "ClaimRev"
}

The control number fields (transactionControlNumber, groupControlNumber, bhtControlNumber) auto-default to safe values if you don't supply them. The full shape of FullClaimEditorViewModel (billing/rendering provider, subscriber, claim, service lines, supplemental info, etc.) is in the API Reference — it mirrors the X12 837P loop structure but with developer-friendly field names.

The response includes the control numbers ClaimRev stamped on the EDI it built, plus the upload result:

{
  "bhtControlNumber": "SHRPRCMEDIB202604271423",
  "groupControlNumber": "142312345",
  "transactionControlNumber": "638503476520012345",
  "uploadFileResult": {
    "message": "...",
    "isError": false
  }
}

These are the values you'll use to find the claim later.

What happens after submission

Once an 837 is in the system:

1. Parse and validate. ClaimRev parses the EDI. Structural problems are surfaced in the file's exceptionMessage and fileStatusName (visible via GetFileList).
2. Route to the payer. Each claim is routed to the appropriate payer using the master payer list (with any account-level overrides applied).
3. Batched send. Claims are not transmitted to payers individually as they arrive — they're sent on a regular processing schedule. Don't expect transmission to be instant after upload.
4. 999 functional ack. Generated by the clearinghouse and reflected on the file record (ackStatusName on GetFileList). Typically available shortly after the file is processed.
5. 277CA claim acknowledgment. Arrives the next day or so. If the payer responds within the window, the 277CA contains the payer's specific acceptance/rejection details. If the payer is silent, ClaimRev generates a generic 277CA so your downstream workflow isn't blocked. Status is reflected on claimAckStatusName.
6. 835 ERA. Days to weeks later, when the payer adjudicates. See Retrieving ERAs.

Downloading the 999 / 277CA bytes

The status fields (ackStatusName, claimAckStatusName) tell you whether an ack has been received, but if you want the raw 999 or 277CA EDI itself, the bytes are available via a legacy ClaimRev API — the same one the customer portal uses for its file-search/download UI. This endpoint is not yet published to the developer-facing Swagger; ask ClaimRev support for access. A clean v1 endpoint to retrieve ack files by input-file id is on the roadmap. 4. Eventually the payer adjudicates and returns an 835 ERA — see Retrieving ERAs.

To see where your claim is in this lifecycle, see Checking Claim Status.

Limits

The endpoint accepts files of normal claim batch sizes. There's no documented hard cap today. If you're submitting unusually large files (thousands of claims in a single envelope) or running into upload size errors, contact ClaimRev support.