For developers
Every clearinghouse job is one API call.
Today Payerworks is an engine you use beside your current clearinghouse: nothing is sent to a payer until that payer’s route opens, and none is open yet. Get a test key here, try the sandbox payers, then write claims and read every payer answer from your own system.
Principles
How it works
Built on the code we bill with
The remittance reader, the claim status reading and the NPI check are the modules the billing company behind Payerworks runs on its own claims and remittances, imported, never copied. The rest, the 837P writer, the 837I and 837D writers, the claim readers and edits, the payer directory, the eligibility and denial explainers, claim tracking, enrollment, the sandbox payers and your account, is Payerworks’ own code, written for this API.
Errors you can act on
Every refusal comes back with a stable code, the path of the field, and a sentence a person can read. A rejection from a payer comes back the same way.
Honest about sending
The API builds, checks and reads every file, and the sandbox payers answer your test files end to end. It does not yet send a file to a real payer: transmission opens one payer at a time as Payerworks’ own routes go live, and until then you send on the connection you already have.
Test it without a call
A test key comes from this page and the sandbox payer answers it right away, with no meeting and no contract. A live key needs a signed business associate agreement first, because a live file carries real patients.
Answers pushed to you
Set a webhook and every answer the 837P claims sandbox makes, and every change to an enrollment request, is posted to your server as it is made, signed under the Standard Webhooks specification, so any of its libraries checks it. An event your server did not take is tried again, and every event can be listed and sent again for 30 days. Up to ten more webhook destinations, each with its own secret and its own event types, are each tried again on their own schedule for more than three days.
What is kept, and for how long
| What | How long |
|---|---|
| A claim, a file or a remittance you send | Never stored, never logged: answered and forgotten. |
| A batch job’s file, and its result | The file until the job finishes, the result 24 hours after. |
| The webhook events queued for you | 30 days. They hold the sandbox’s invented answer and, of what you sent, only claim references and control numbers. |
| A fingerprint of a request sent with an Idempotency-Key | 24 hours. Never the request itself. |
| Enrollment providers, requests and their PDFs | A test key’s providers and requests, 30 days after their last change, and its PDFs 30 days after upload. A live key’s, until you delete them. |
Your call counts stay with your account, and your webhooks, destinations, notice address and key names until you remove them. Every detail, backups included.
One call
Check a claim before it goes
A claim is JSON in the 837P’s own structure. One call answers every reason a payer’s front end would refuse it, each with the field to fix.
curl "$PAYERWORKS_BASE_URL/v1/claims/validate" \
-H "Authorization: Bearer $PAYERWORKS_API_KEY" \
-H "Content-Type: application/json" \
-d @claim.jsonDocs
Every job, its own page
Each page has the request, how to read the answer, what to do when it is refused, the code lists and an example that runs. Every page is also markdown for a coding agent.
Start here
- OverviewPayerworks API docs by job: eligibility, claim status, claims, remittances, enrollment, events and keys, with quickstarts, examples and markdown for agents.
- Coding agentsPoint a coding agent at the Payerworks docs, the OpenAPI document and the MCP server, with prompts to paste and a check of what it builds against the sandbox.
Quickstarts
- A sandbox claim to its 835Send one invented claim to the Payerworks sandbox payer and read its 999, its 277CA and its 835 back, each explained, with a test key, in a few minutes.
- A first 271, explainedWrite an eligibility question as a 270, get a 271 back from the eligibility sandbox, and read the deductible, out-of-pocket and copays in plain English.
- Following an eventSet a webhook, run the claims sandbox, check each event’s signature on your server, and list or send again the events Payerworks recorded for your key.
- The enrollment sandboxCreate an invented provider, request enrollment with the sandbox payer PWSANDBOX, submit it, and advance it through its statuses one step at a time.
- A first 275Announce an attachment on a claim, then write that attachment as an X12 275 under the same control number, ready for you to send on your own connection.
By job
- EligibilityWrite eligibility questions as 270s, explain any 271 per patient, find a patient again after a no-match, put plans in order, and print an answer.
- Claim statusWrite claim status questions as 276s, explain each 277 answer with the next step and when to ask again, and follow up on your open claims.
- ClaimsCheck claims against one published edit table, write 837P, 837I and 837D files, plan corrected and void claims, and run the claims sandbox.
- AcknowledgmentsExplain every rejection in a 999 or a 277CA with what to fix in your claim data, and track each claim from the 837s, 999s, 277CAs and 835s you hold.
- Remittances and denialsExplain an 835 claim by claim, say each denial as the next step, write appeal letters, and find duplicates, deposits, recoupments and filing windows.
- AnalyticsCount your own denials and payments, check payments against your fee schedule, check a claim against your past denials, and rank open denials.
- Documents and attachmentsDraw claims on the CMS-1500, print remittances and eligibility answers, fill Medicare’s appeal forms, and write attachments as an X12 275.
- Prior authorizationWrite a prior authorization request as a 278, explain the payer’s response, run the authorization sandbox, and check Medicare’s published lists.
- Patient estimatesEstimate a patient’s share from a 271, lay out a Good Faith Estimate, find a replacement window and a poverty guideline percent, and check a charges file.
- Payer directorySearch payers and plan programs from public federal files, with a payer ID only where the payer publishes it. It is not a list Payerworks sends to.
- EnrollmentCreate providers, request transaction enrollment with a payer, answer its tasks and upload its PDFs, import many at once, and run the enrollment sandbox.
- Events and webhooksReceive signed events at your webhook or several destinations, check each signature, list every event for 30 days, and send one again.
- Keys and your accountTest and live keys, your account’s rate and usage this month, named keys, rotation that keeps the key id, your notice address, and the hosted MCP server.
- SFTP file dropMake an SFTP user under your own SSH key, drop 837P claim files in one folder, and read the answers Payerworks writes to another, where the drop is open.
- Batch jobsRun up to 1,000 calls to one route from one uploaded file, or write one 270 of up to 7,500 questions, and fetch the result for 24 hours.
- Organizations and membersMake an organization for your account, invite people with a role, sign in with an authenticator app, and manage keys as a member while keys call the API.
Reference
- Every errorEvery refusal code the Payerworks API answers, with its HTTP status and what it means, how a refusal is shaped, and which ones a client should retry.
- CompatibilityWhat may change under /v1 without notice, what counts as a breaking change, how much notice a removal gets, and how a deprecation is marked.
- ChangelogEvery dated change to the Payerworks API: what shipped, how it was before and how it is now, the sandbox support, and what it means for an integration.
Every route is under /v1. The base URL is shown with your key. The whole contract, machine-readable, is openapi.json.
Every rate, size and item limit, read from the code that refuses by it: payerworks.com/limits. What was measured this month, with any incident and its feed: payerworks.com/status.
JavaScript · Python · MCP server
Your key’s rate, its calls by day and your webhook are in the console. Open the console.
Talk to us
What happens next
- 1
A person at Payerworks reads what you sent, usually within a business day.
- 2
One reply by email names the next step: our trading partner details, where each of your payers stands, or a key for the API.
- 3
Nothing follows unless you answer. There is no sales sequence behind this form.
Or write to hello@payerworks.com.