Claim.MD API

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

★ Only Publicly Available OpenAPI DocumentHealthcareClinical 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.

Install Jentic One Beta

Connect the Claim.MD API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Claim.MD API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Claim.MD 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

GET STARTED

Start building with Claim.MD API

Explore with Jentic

View OpenAPI Document

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 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 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.

FAQs

Specific to using Claim.MD 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.

Claim.MD API

Connect the Claim.MD API to your agent

Capabilities

Start building with Claim.MD API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs