Skip to main content

Changelog

Breaking changes, new endpoints, and deprecations land here. For exhaustive endpoint-level detail, see the API Reference.

2026-10-23​

  • Added: POST /api/SharpRcm/v1/CreateClaimEdi builds institutional (837I) and dental (837D) claims. Set the new claimType field to institutional or dental; leave it off and an 837P is built as before. See Building an 837I and Building an 837D, and the new Create claim EDI (institutional, 837I) and (dental, 837D) samples under Practice Admin → API Checks.
  • Changed: CreateClaimEdi sets GS08 and ST03 from the claim type when envelop.gs08 is empty; it used to send them empty. A request whose envelop.gs08 names a different claim type from claimType is now rejected with a 400 instead of building one claim type labelled as another.
  • Docs: the 837I field map and 837D field map list every field of the request and the loop, segment and element it is written to in each claim type, plus the fields that are accepted but not sent. Like the 837P map, they are checked against the API on every build.
  • Fixed: in 837Is built from JSON (CreateClaimEdi) or edited in the portal:
    • Inpatient adjudication (2320 MIA) elements are written to and read from their correct positions.
    • Other payers send their claim control number (2330B REF*2U), line date ranges are sent as RD8, and line amounts use the 837I qualifiers (AMT*GT, AMT*N8, claim AMT*F3).
    • Provider loops that do not allow a taxonomy or an address (2310D, 2420C, 2330C, 2330F, 2330G) no longer carry one, and admitting and reason-for-visit diagnoses no longer carry a present-on-admission indicator.
    • PWK05 AC for transmission code FT on a line is now sent.
  • Fixed: in 837Ds built from JSON or edited in the portal, the missing-teeth segment (DN2) and the other payer's remaining patient liability (2320 AMT*EAF) are now sent, the assistant surgeon's taxonomy is sent as PRV*AS (2310D, 2420B; it was PE, which the 837D rejects), and other payers' provider loops no longer carry segments the 837D does not allow there (2330D/2330H PRV, 2330G N3/N4). A line's prior placement date (2400 DTP*441) is now accepted as a valid qualifier, and a received 837D keeps the other payer's assistant surgeon (2330H).

2026-10-22​

  • Docs: how to send a secondary claim through POST /api/SharpRcm/v1/CreateClaimEdi, with the primary's adjudication at claim level (2320 CAS) or per service line (2430 SVD/CAS), the field-to-837P mapping and the balancing rule. Both shapes are also runnable samples under Practice Admin → API Checks. See Sending a secondary claim. CreateClaimFromForm sends primary claims only.
  • Docs: the CreateClaimEdi Field Map lists every field of the request and the 837P loop, segment and element it is written to, plus the fields that are accepted but not sent. It is checked against the API on every build.
  • Fixed: in 837Ps built from JSON (CreateClaimEdi) or edited in the portal:
    • The billing provider's taxonomy (2000A PRV) is no longer dropped when a pay-to plan is sent.
    • The payer's tax id (2010BB REF*EI) and a serum creatinine test date (2400 DTP*739) are now written inside their loops instead of ahead of them.
    • Other payers' loops no longer carry segments the 837P does not allow there (2330B REF*G2/REF*LU, 2330D PRV, 2330E N3/N4).
    • Form identification loops (2440) are written once, not twice.
    • The third EPSDT referral code, line-level ambulance certification (2400 CRC*07) and PWK05 AC for transmission code FT on a line are now sent.
  • Fixed: a received 837P keeps a service line's ambulance drop-off location (2420H); it was lost on parse.

2026-10-21​

  • Added: the Payer Simulator supports institutional (837I) and dental (837D) claims as well as professional. Its 835 writes each service line as billed: AD:<CDT code> for dental, NU:<revenue code> for an institutional line with only a revenue code, and HC:<HCPCS> with the revenue code in SVC04 otherwise. Institutional claims carry CLP08 facility type and CLP09 frequency from your type of bill. Repriced ERAs get the same fix. See Testing EDI Responses with the Payer Simulator.
  • Added: the Payer Simulator works one submission (one file from your EMR) at a time. GET /api/PayerSimulator/v1/GetTestPayerBatches lists your submissions newest first with how many claims are at each step and which; GetTestPayerClaims takes uploadBatchId and returns each claim's nextStep; and SendToTestPayer takes optional claimIds to send just one submission. In the portal, a step bar on the Test Payer screen shows what to do next.

2026-10-20​

  • Added: the test payer is now the Payer Simulator, with more of the cycle on demand. POST /api/PayerSimulator/v1/SendToTestPayer sends your test account's ready claims to the test payer immediately instead of waiting for the scheduled batch; POST /api/PayerSimulator/v1/SendClientAcknowledgments builds ClaimRev's 277 now, including claims that failed our edits; and POST /api/PayerSimulator/v1/SendPayer999 returns the payer's 999, where the new TEST999REJECT scenario rejects a claim and the rest of its transaction set is resent. SendPayer835 takes a new negativeBalance (0 debit, 1 a $0.00 notification with a PLB forward balance) for 835s that net below zero. GetTestPayerClaims now filters by patient last name, patient control number and status, lists ready and errored claims too, and returns the received, sent, last 277 and ERA dates. See Testing EDI Responses with the Payer Simulator.
  • Changed: the test payer's 277CA now reads like a payer's: accepted claims carry A2:20:PR (WQ), and ClaimRev's own clearinghouse statuses are no longer repeated as the payer's. Payer responses are available once a claim is Sent To Payer; Merged To Payer is no longer enough, as a payer cannot answer a file it has not received.
  • Added: register your own public key on a key-based client application instead of downloading a key file, so the private key can be generated and kept in your own key vault or HSM. In the portal, choose Use your own public key from the application's actions menu. The key must be RSA, 2048 bits or larger, in PEM format; sign with RS256 using the Key ID and User ID the portal shows. Sign-in is otherwise unchanged. See Authentication.

2026-10-19​

  • Added: the test payer. Claims from a test account now get payer responses on demand: ask for the payer 277CA or the 835 for claims you sent, and ClaimRev processes it like a real payer's, so you receive your 277 and 835 through your usual delivery within seconds. The claim's subscriber ID picks the outcome: accepted, rejected, pended, paid, denied, reversed, corrected or split. New endpoints GET /api/PayerSimulator/v1/GetTestPayerClaims, POST /api/PayerSimulator/v1/SendPayer277Ca and POST /api/PayerSimulator/v1/SendPayer835, plus a Test Payer screen in the portal. Requires the payer-simulator:send role. See Testing 277CA and 835 Responses with the Test Payer.

2026-10-16​

  • Added: sign in to the account MCP endpoint, https://api.claimrev.com/mcp/account, from your assistant. Claude, Claude Desktop and Claude Code open a browser, you sign in with your ClaimRev login, and the assistant stays signed in on its own. Add the server with OAuth Client ID 395403588760764418 (no secret); in Claude Code also pass --callback-port 33418. The endpoint publishes standard MCP sign-in metadata at /.well-known/oauth-protected-resource/mcp/account. Key-file tokens still work, and in production no longer need x-auth-tenant on this endpoint. Production only for now. See MCP Server.

2026-10-15​

  • Added: a signed-in MCP endpoint, https://api.claimrev.com/mcp/account, for AI assistant tools that work on your own account. Its first tool, list_sharpinsight_reports, lists the Sharp Insight reports your account can run, with what each one answers, its inputs and its API route. It lists reports only; it does not run them. Sign in with a ZITADEL key file and send Authorization: Bearer plus x-auth-tenant: zitadel; the application needs a role with sharpinsight:read. The public /mcp endpoint and its payer tools are unchanged. See MCP Server.

2026-10-14​

  • Added: SharpRevenue results as a finished HTML page or PDF. New optional responseFormat on RunSharpRevenue (Json default, JsonWithHtml, Html, JsonWithPdf, Pdf), and ?format= on PostEligibilityRequestFile, CheckTransactionStatus and GetSharpRevenueOutput. Html and Pdf return the document itself with X-ClaimRev-Result-Id, X-ClaimRev-Status, X-ClaimRev-Retry-Later and X-ClaimRev-Fatal-Error headers so you can still poll. Leaving responseFormat out returns JSON exactly as before. See SharpRevenue Reports as HTML or PDF.
  • Added: a QR code and link on the HTML and PDF that open the result. Optional includeQrCode and qrCodeUrl on the request turn it off or point it at your own system; a practice-level Show QR code setting sets the default.
  • Added: response fields resultHtml and resultPdf (only when you ask for JsonWithHtml / JsonWithPdf), and isMock, which is true when a result came from the test-environment mock library rather than a payer.

2026-10-13​

  • Added: API sign-in with a ZITADEL key file, alongside Azure AD B2C client secrets. Key-file applications sign a short-lived assertion with their private key and exchange it for a token (JWT bearer grant) at auth.claimrev.com (auth-staging.claimrev.com for test), and send x-auth-tenant: zitadel on every API call. Existing B2C integrations are unchanged. See Authentication.
  • Docs: Authentication covers both sign-in methods side by side, with C# and Python examples for key files. Client Applications covers generating, rotating and revoking keys. Token lifetime guidance now says to read expires_in rather than assume one hour.

2026-10-08​

  • Docs: new Client Applications page covering how to get a Client ID, request a new application, generate a secret, set roles, rotate a secret without downtime, and revoke the old one. Authentication now points there instead of Client Connect, and no longer says rotation requires contacting support.

2026-09-25​

  • Changed (non-breaking): POST /api/PaymentAdvice/v1/CreateDerivedClaim needs only paymentAdviceId, the ERA line to derive from. matchedClaimId is now optional and defaults to the claim that line is matched to. paymentInfoId is no longer used; requests that still send it keep working. See Finding the ids.
  • Changed (breaking): on CreateDerivedClaim, subscriberAddress1, subscriberAddress2, subscriberCity, subscriberState, subscriberZip, subscriberBirthDay and subscriberGender are replaced by patientAddress1, patientAddress2, patientCity, patientState, patientZip, patientBirthDay and patientGender. They always described the patient, not the policyholder. They are now optional: each defaults to the patient on the primary claim, so most requests can leave them out. See Subscriber, patient and policy fields.
  • Changed: CreateDerivedClaim returns 400 or 404 with a message explaining what is wrong, instead of an empty 204 No Content. If your integration checks for 204, check for a non-200 status instead.
  • Fixed: CreateDerivedClaim now only accepts an ERA line and claim in an account your credentials can access.
  • Docs: Submitting a Claim now explains where the relationship code goes when the patient is a dependent, and Retrieving ERAs maps the derived-claim subscriber, patient and policy fields to the 837.

2026-06-03​

  • Added: POST /api/ManualClaimEntry/v1/CreateClaimFromForm — create a claim by sending CMS-1500 or UB-04 form boxes as JSON; ClaimRev maps them, builds the 837 (professional or institutional), and submits it. The simplest, no-EDI way to create a claim. See Creating a Claim from Form Boxes.

2026-04-27​

  • Added: public Swagger document group at /swagger/public/swagger.json — surfaces external integrator endpoints only. Internal admin endpoints are filtered out.
  • Docs: Developer portal launched at developer.claimrev.com with hand-written narrative docs (concepts, quickstart, authentication, guides) and the full Redoc-rendered reference.