Getting started
Overview
What Claim House is, what you can build on it today, and where to start.
Claim House is a dental clearinghouse with an API. Send JSON, get a dental payer's answer back as one readable object, and let Claim House deal with the payer connections behind it.
Building with Claude, Cursor or an agent? Connect the MCP server and the agent can do everything the API does with your test key: find payers, check eligibility, send claims with attachments and read ERAs. One command in Claude Code (below); Build with AI has Cursor, Claude Desktop and every other client, the prompts that work, and the OpenAPI document, llms.txt and markdown pages (add .md to any docs address) for an agent that writes the integration itself.
claude mcp add --transport http claimhouse https://sandbox.myclaimhouse.com/api/mcp \
--header "Authorization: Bearer $CLAIMHOUSE_KEY"What you can do today#
| Product | What it does | Status |
|---|---|---|
| Eligibility | Check a patient's dental coverage and benefits: status, maximums, deductibles, coverage by category and per procedure code. | Available with test keys. Live checks are not open yet: see Going live. |
| Claims | Send dental claims as JSON: validated before anything is sent, batched into 837D files, and followed through the clearinghouse's 997 and the payer's 277 on a timeline. | Available with test keys, in the sandbox network. Live claims are not open yet. |
| Attachments | Send X-rays, charts and narratives with a claim: upload JPEG or PNG images, close the attachment to get its number, and the claim's 837D carries it. Answer a payer's request for more. | Available with test keys, in the sandbox attachment network. Live attachments are not open yet. |
| ERAs | Read the payers' remittances (835) as JSON: each payment matched to its claim, which becomes paid or denied, every adjustment in plain words; post them when your system has. | Available with test keys: the sandbox sends remittances. Live ERAs arrive once live mode opens. |
| Predeterminations | Ask a payer what it would pay before the treatment: a predetermination travels as a claim with no service dates and comes back with the payer's estimate; convert it into a claim once the work is done. | Available with test keys: the sandbox sends estimates. Live predeterminations open with live claims. |
| Payers | Look up the dental payers Claim House reaches and what each one supports. | Available. |
| Events and webhooks | Get a signed webhook when a check completes or a claim moves, and replay any event. | Available. |
| Payer enrollment | Track the paperwork some payers need before they take a provider's claims or send ERAs: the method from the payer directory, the status and dates. | Available. |
| SFTP for batch partners | Drop 837D files on a private SFTP account instead of calling the API, and read the 997, 277 and 835 files back. Every claim is also a claim in the dashboard and the API. | Available with test keys: test files go to the sandbox network. Live files are not open yet. |
| Offices, providers and the current key | Read the offices of your organization, keep its providers' NPIs and licenses, and read the key you are calling with. | Available. |
Already speak X12? You can skip the API for claims: SFTP for batch partners takes your 837D files and writes the acknowledgments, statuses and remittances back as files.
Start here#
- With an AI tool: connect the MCP server (above), then ask it to check coverage for member
CH-ACTIVE-FULLat your test office. Build with AI has the prompts that work. - By hand: follow the Quickstart. It takes about five minutes, runs entirely in the sandbox, and ends with a rejected check you fix and resend.
- Read Authentication and keys and Errors, retries and idempotency before you write real integration code.
- Use the API reference for every field, or give the OpenAPI document to your code generator.
How the API works#
- The base URL is
https://sandbox.myclaimhouse.com/api/v1. Requests and responses are JSON, and every field name issnake_case. - Every request carries an API key as a bearer token. A test key only ever reaches the sandbox: nothing is sent to a payer and nothing is billed.
- Every response has an
x-request-idheader. Quote it when you contact support. - Lists return
{ "data": [...], "next_cursor": ... }. Pass the cursor back to get the next page. - A POST or a PATCH needs an Idempotency-Key header, so a request that timed out can be repeated safely; a search sent as a POST takes none.
curl "https://sandbox.myclaimhouse.com/api/v1/me" -H "Authorization: Bearer $CLAIMHOUSE_KEY"Lists and pages#
A list answers with a page of items and a cursor for the next one. Pass limit (1 to 100, default 25) to choose the page size, and pass the next_cursor of one page as cursor to get the next. next_cursor is null on the last page. A cursor is opaque: pass it back unchanged.
curl "https://sandbox.myclaimhouse.com/api/v1/payers?limit=2" -H "Authorization: Bearer $CLAIMHOUSE_KEY"{ "data": [{ "id": "pyr_...", "object": "payer" }, { "id": "pyr_...", "object": "payer" }], "next_cursor": "..." }