Skip to the page
Chapters

Resources

Changelog

What is available in the API and the docs today, and what is still to come.

This is version 1 of the API. Everything under "Available now" works today with a test key. Live mode is not open yet: see Going live.

Available now#

  • Everything through MCP. The MCP server has a tool for each of the API's 69 endpoints, generated from the same definitions, so an agent can send a claim, upload its X-ray (content_base64), and read the ERA without leaving its MCP client. Writes take an idempotency_key argument; a read-only key can list every tool but is refused the ones that need submit.
  • PNG attachments. Upload a PNG as well as a JPEG: it is converted to a JPEG at upload (transparency on white, its header checked before it is decoded, an animated PNG refused), and the document says converted_from: "png". PDF is not accepted: export the page as an image. The dashboard's Attachments list shows a thumbnail of each attachment's first image. See Attachments.
  • Reproducing a report from the lists. GET /claims takes sent_from and sent_to (claims first sent in a range: handed to the network, never a void transaction) and GET /eras received_from and received_to; either end alone is open. A void transaction is never counted as a claim in a report, and first-pass acceptance counts a rejected claim as answered while it is corrected and sent again. See Reports.
  • Payer enrollment. Start, list, read and update the enrollment of a provider with a payer for claims, ERAs, or ERAs with EFT: the method comes from the payer directory, the status moves along a fixed table, every change is audited. A claim to a payer that needs claims enrollment the provider does not have gets the ENROLLMENT_NOT_ACTIVE warning (it replaces PAYER_ENROLLMENT_REQUIRED, and never blocks). See Payer enrollment.
  • Usage and billing. GET /usage prices a month's usage by your agreement (eligibility tiers, flat rates, the monthly minimum and its introductory months, late usage as adjustments); GET /usage/units lists the records it is counted from, each billable check with its tier price; GET /statements and GET /statements/{id} read the monthly statements, which never change. A month that has not begun answers 422. The Usage & billing screen shows the same figures and downloads the records as CSV; the dashboard shows the month at a glance. Some decisions are still to be confirmed: see Pricing and usage.
  • Predeterminations. Ask a payer what it would pay before the treatment: POST /claims with kind predetermination and no service dates (the 837D carries CLM19 PB and no service date). The payer's estimate (a remittance with status 25) moves it to returned, with its estimate, and predetermination.returned; it is never a payment. Convert a returned one into a claim. GET /claims lists claims only unless kind=predetermination is given. In the sandbox every predetermination the payer accepts is answered with its estimate. See Predeterminations.
  • ERAs. List and read the payers' remittances (835) as JSON, each payment matched to its claim and each adjustment in plain words; read your own remittance as an 835 (bank numbers cut to their last four); match a payment by hand; post an ERA, or reconcile a claim. Claims gain the states paid, denied and reconciled and their payment; an accepted, paid or denied claim can be corrected as a replacement with resubmit. Events era.received, claim.paid, claim.denied and claim.payment_reversed. Sandbox scenarios CH-PAID-ERA and CH-DENIED, and the test payer CHTEST. See ERAs and posting.
  • Corrections, voids and payment figures. Cancel a correction before it goes out; a claim the payer has is always voided by a void transaction; a returned predetermination can be voided (unless converted). A claim's payment gains outcome, and its allowed is its current payment's; claim.paid and claim.denied carry claim_payment, the claim's figures. Every amount on the claim object is a decimal string (fee and totals.charge too), and a fee can be sent as one. Cancelling a correction undoes its edits. An ERA says what posting it reconciles (postable_count, and postable per payment). Matching a payment to a claim of another payer takes confirm_payer; reading ERAs takes read, posting and matching take read and submit. The sandbox answers a replacement or a void of a claim it paid with the reversal. An 835 that cannot be read is quarantined at once.

Developer tools#

  • Events and webhooks. Events are recorded when an eligibility check completes (eligibility.completed) and when an API key is created or revoked (api_key.created, api_key.revoked). Webhook endpoints are signed (X-ClaimHouse-Signature), retried, and can be replayed. See Events and webhooks.
  • OpenAPI 3.1 document at /docs/openapi.json, generated from the API's own definitions.
  • MCP server at /api/mcp for AI tools: a tool for every API endpoint (claims, attachments with the image as base64, ERAs, patients, enrollments, events, webhooks, usage and the rest), with the same key, permissions, validation, idempotency and errors as the API, and curated tools that explain eligibility answers and rejections. See Build with AI.
  • Sandbox page in the dashboard: the scenario table, a first-check command, and Reset test data for owners and admins (deletes the organization's test-mode checks, events and deliveries).
  • These docs, with a markdown version of every page, llms.txt and llms-full.txt. See Build with AI.

API#

  • Account. GET /me names the calling key, its mode, its permissions and its organization.
  • Payers. List, search and get the payer directory, with filters by transaction and enrollment. The directory is also public at /network. See Payers.
  • Offices. List and get your organization's offices, and register one with the attachment network.
  • Attachments. Create an attachment (for a claim, or on its own with its patient, insured and dates of service), upload its JPEG images (rewritten without their metadata; the same image again is answered with the document already there, and a retry with its Idempotency-Key is replayed), close it to get its number, and put it on a claim (at most five), whose 837D then carries it in PWK and NTE. List (also by request_id or idempotency_key), read, discard an open one, remove a document, preview an image and list the document types. Claims gain attachments and the findings ATTACHMENT_REQUIRED, ATTACHMENT_OPEN, ATTACHMENT_RECOMMENDED and REMARKS_NAME_ATTACHMENT; a validated claim not yet queued can still be edited (it is validated again at once), and a voided claim gives up its attachments. Events attachment.completed and payer_request.received. See Attachments.
  • Payer requests. List, read, record by hand and answer a payer's request for more about a claim, with a solicited attachment. Sandbox scenarios CH-ATTACH-REQUIRED and CH-SOLICITED.
  • Providers. List, add, get and update the dentists who render treatment, with their NPIs, state licenses and taxonomy codes. Each claim names one of them as the rendering provider.
  • Claims. Create, validate, list, read, correct, submit, resubmit and void dental claims, follow each on its timeline and read the 837D it went out in. In test mode a sandbox clearinghouse answers with real 997 and 277 files on a compressed clock, with claim events (claim.submitted, claim.accepted, claim.rejected and more) and batch.acknowledged. See Claims.
  • Eligibility. Run a check, read one and list them, by status, office, request or your own tenant_reference. Answers with plan, maximums, deductibles, coverage by category and detail for each procedure code; rejections with the reasons to fix and a way to resend with parent_id; the billing reason on every check; reuse of recent answers. See Eligibility.
  • Sandbox. Scripted payers chosen by member ID, and a list of them. See Sandbox and scenarios.
  • Conventions. Bearer API keys with read and submit permissions, snake_case JSON, one error shape, Idempotency-Key on every POST and PATCH, cursor pagination. See Authentication and keys and Errors, retries and idempotency.

Planned#

These are not available yet. Each has a short page that says what is planned: SFTP for batch partners and SDKs. Live eligibility checks, live claims and live attachments open when live mode does.