Claim.MD API

Name: Claim.MD API API
Brand: Claim.MD API
Availability: InStock

★ Only Publicly Available SpecHealthcareClinical DataapiKey16 EndpointsREST

For Agents

Submit healthcare claims, run eligibility checks, and pull electronic remittance advice through Claim.MD. Useful for any RCM or billing agent that needs to talk to a clearinghouse on behalf of a US provider.

Quickstart

Get started with Claim.MD API in minutes using your preferred integration method.

# Add to your MCP client config (Claude Desktop, Cursor, Windsurf)
{
  "jentic": {
    "url": "https://api.jentic.com/mcp",
    "auth": "oauth"
  }
}

# Then ask your agent:
"submit a healthcare claim batch"

# → Jentic returns the GET /events tool with parameter schema, agent executes.

Capabilities

What an agent can do with Claim.MD API API.

Submit batches of healthcare claims via /services/upload and track them with /services/uploadlist

Run real-time eligibility checks using either X12 270/271 or a JSON/XML payload

Retrieve Electronic Remittance Advice in 835, PDF, or structured data form once a payer responds

Modify, archive, or appeal a previously submitted claim through the matching /services endpoint

GET STARTED

Start building with Claim.MD API API

Explore with Jentic

View OpenAPI Spec

Jentic publishes the only available OpenAPI specification for Claim.MD API, keeping it validated and agent-ready.

Jentic publishes the only available OpenAPI specification for Claim.MD API, keeping it validated and agent-ready. Claim.MD is a healthcare claims clearinghouse used by US providers and billers to submit electronic claims, run eligibility checks, retrieve electronic remittance advice (ERA), and manage appeals and provider enrollments. The API exposes the full claim lifecycle through a single /services/* surface, including X12 270/271 eligibility, 835 remittance retrieval, and PDF or structured ERA data. Authentication is via an AccountKey query parameter taken from the Claim.MD web portal.

Use Cases

Patterns agents use Claim.MD API API for, with concrete tasks.

★ Daily claims submission and reconciliation

A medical billing service uploads the day's claims to /services/upload as an X12 837 batch, then polls /services/response and /services/eralist to reconcile payer responses and remittances. Claims that come back with errors are corrected through /services/modify or escalated through /services/appeal. The clearinghouse abstracts the per-payer connectivity, so the billing service only manages one credential.

Upload a 50-claim 837 batch to /services/upload, then 24 hours later pull /services/eralist and match each ERA to the originating claim

Real-time eligibility verification at front desk

A patient-intake tool calls /services/eligdata with the patient and payer identifiers and shows benefit details before the visit. For partners that already speak the X12 standard, /services/elig accepts a 270 request and returns the 271 response unchanged. This shifts denial risk left, before the encounter happens.

POST /services/eligdata with patient demographics and payer id, then surface co-pay and deductible from the response

Automated denial appeals workflow

When an ERA pulled via /services/era835 indicates a denial, a workflow agent reads the reason codes, retrieves the original claim through /services/response, attaches supporting documentation via /services/notes, and submits an appeal through /services/appeal. The same endpoint set handles correction and resubmission via /services/modify when the issue is fixable rather than appealable.

Identify a denial in the latest ERA, attach a note explaining medical necessity, and POST an appeal to /services/appeal

Agent integration via Jentic

Through Jentic, an RCM-focused agent can resolve intents like 'check eligibility for this patient' to the right Claim.MD endpoint without learning the difference between /services/elig and /services/eligdata. The AccountKey is held in the Jentic credential vault and only attached to the request at execution time.

Search Jentic for 'run an eligibility check', load the schema for /services/eligdata, and execute it with the parsed patient and payer details

Key Endpoints

16 endpoints — jentic publishes the only available openapi specification for claim.

METHOD

PATH

DESCRIPTION

POST

/services/upload

Upload a batch of claims

POST

/services/response

Get a claim response

POST

/services/elig

Submit X12 270 eligibility request

POST

/services/eligdata

Submit JSON/XML eligibility request

POST

/services/eralist

List electronic remittance advice

POST

/services/era835

Get ERA in 835 format

POST

/services/appeal

Submit a claim appeal

POST

/services/payerlist

List available payers

POST

/services/upload

Upload a batch of claims

POST

/services/response

Get a claim response

POST

/services/elig

Submit X12 270 eligibility request

POST

/services/eligdata

Submit JSON/XML eligibility request

POST

/services/eralist

List electronic remittance advice

Why though Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Claim.MD AccountKey values are stored encrypted in the Jentic vault and added to the AccountKey query parameter at execution time. The agent never sees the raw key, so a leaked transcript cannot be replayed against the clearinghouse.

Intent-based discovery

Agents search Jentic with intents like 'submit a claims batch' or 'pull this week's ERAs'. Jentic returns the matching /services endpoint with its input schema, abstracting the difference between X12 and JSON variants.

Time to first call

Direct integration with Claim.MD: 5-10 days to learn X12 837/270/271/835, model the response shapes, and handle webhook callbacks. Through Jentic: under a day for the JSON variants, since Jentic loads the schema and the agent does not need to parse X12 by hand.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Complementary

Civic Auth API

Civic Auth gates the user identity that submits or appeals claims on behalf of a provider.

Use Civic Auth ahead of Claim.MD when the workflow needs verified identity before a billing action.

Complementary

Clarivate API

Clarivate exposes biomedical reference data that supports coding decisions before a claim is submitted.

Pair Clarivate (clinical reference) with Claim.MD (claim submission) when codes need to be researched before sending.

Alternative

CiviCRM REST API

CiviCRM stores constituent records but does not handle insurance billing — useful only as a contrast.

Choose CiviCRM only when the user is a non-profit managing donors, not a provider submitting claims.

FAQs

Specific to using Claim.MD API API through Jentic.

Why is there no official OpenAPI spec for Claim.MD API?

Claim.MD does not publish an OpenAPI specification — its developer reference is a set of HTML pages and PDF samples. Jentic generates and maintains this spec from that documentation so AI agents and developers can call Claim.MD through structured tooling. It is validated against the live API and kept up to date. Get started at https://app.jentic.com/sign-up.

What authentication does the Claim.MD API use?

Claim.MD uses an AccountKey passed as a query parameter on every request. The key is generated under Settings > Account Settings in the Claim.MD web portal. Through Jentic, the key is stored encrypted in the credential vault and attached to outgoing requests only at execution time.

Can I submit claims and retrieve ERAs through this API?

Yes. POST /services/upload accepts an 837 batch, /services/response returns the parsed payer response, and /services/eralist plus /services/era835 expose the resulting electronic remittance advice. PDF and structured-data variants are available via /services/erapdf and /services/eradata.

How do I run an eligibility check through Jentic?

Search Jentic for 'check patient insurance eligibility'. Jentic returns POST /services/eligdata with its input schema (patient demographics, payer id, service date). Load the schema, fill the values, and execute — the response is the parsed 271 in JSON without you having to handle X12 directly.

What are the rate limits for the Claim.MD API?

The OpenAPI spec does not declare formal rate limits. Throughput is governed by your Claim.MD plan and the connectivity of each downstream payer; treat 429 responses as a backoff signal and confirm sustained submission volume with Claim.MD support.

Does this API support webhook callbacks for claim status?

Yes. The /Webhook entry in the spec defines the payload Claim.MD sends to a URL you configure on your account. Pair it with /services/response to fetch the full payer response when a status change is signalled.