Payerworks writes and explains files; it sends nothing to a payer. Every file a route writes says transmitted: false, and is yours to send on your own connection. A test key is for invented data only, never a real patient.
Start here
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 in words, 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 words.
- 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 as the 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.
- Analytics from your own filesCount 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 estimates and moneyEstimate 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.
- The 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.
- Transaction 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.
- The 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.
- Compatibility and deprecationWhat 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.
For agents and tools
- Every page as markdown: add .md to its address, as /docs/eligibility.md. Each page also has a Copy for agent button.
- /docs/llms.txt: the docs’ index, and /llms-full.txt: every page whole, in one file.
- /openapi.json: the whole contract, with a real example for every route.
- /sdk/payerworks.mjs: JavaScript. An ES module for Node 18 or later, on your server: one method per route, typed in JSDoc, and uploadDocument for an enrollment task’s PDF. Your key is a bearer key, so never put it in browser code.
- /sdk/payerworks.py: Python. For Python 3.9 or later, the standard library only: one method per route.
- /sdk/payerworks-mcp.mjs: MCP server. For an AI agent: run it with node over stdio, and each route that answers a question is a tool, with the reads of your account and your enrollment requests, except the routes that answer with a PDF, the two that read a picture with a model, and the enrollment export. Setting, removing or testing your webhook, sending an event again, and every change to a provider, an enrollment request, a task, a document, a key or a destination stay with you. One tool writes to your account: a sandbox claims run records its events and posts them to your webhook, when one is set.
- /docs/changelog.atom: the changelog as an Atom feed.