# Changelog > One entry per dated change, newest first, in one fixed form. Also as a feed. Page: https://payerworks.com/docs/changelog · Markdown: https://payerworks.com/docs/changelog.md > 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. Newest first. Also as an Atom feed: [/docs/changelog.atom](https://payerworks.com/docs/changelog.atom). What may change without notice, and how much notice a removal gets, is the [compatibility policy](https://payerworks.com/docs/compatibility). ## 10/20/2026: Organizations, members and roles, off until Payerworks turns them on What shipped: - An organization for an account: its members, each with a role (owner, admin, developer or viewer), invitations by email that work for 7 days, and one role table every organization shares (GET /v1/org/roles). - A member signs in at payerworks.com/console with a password and a code from an authenticator app, always, and manages the account’s keys, webhooks, enrollments, SFTP user and notice address as far as the role allows. A sign-in never makes a call that carries data: claims, eligibility, files, sandboxes, MCP and batch jobs take a key. - An owner may choose that only signed-in members make, rotate and revoke the account’s keys (key_management: members_only). Before: Every key of an account managed every other, and there were no members, roles or sign-in. Now: Keys still call the API. People manage the account through the console, each within a role, and the last owner of an organization is never removed or demoted. Sandbox support: Off until Payerworks turns organizations on: until then nobody can sign in, a sign-in’s token is answered 501 org_not_offered, and a key is answered 401 org_session_required on every route but GET /v1/org/roles, which answers any key. Existing integrations: None: thirteen new routes. Every key route answers as before unless an owner chooses members_only, and then only POST /v1/keys, DELETE /v1/keys/{id} and POST /v1/keys/{id}/rotate refuse a key, with keys_managed_by_members. Routes: [GET /v1/org/roles](https://payerworks.com/docs/organizations#get-v1-org-roles), [GET /v1/org/memberships](https://payerworks.com/docs/organizations#get-v1-org-memberships), [POST /v1/org](https://payerworks.com/docs/organizations#post-v1-org), [GET /v1/org](https://payerworks.com/docs/organizations#get-v1-org), [PUT /v1/org](https://payerworks.com/docs/organizations#put-v1-org), [GET /v1/org/members](https://payerworks.com/docs/organizations#get-v1-org-members), [PUT /v1/org/members/{id}](https://payerworks.com/docs/organizations#put-v1-org-members-id), [DELETE /v1/org/members/{id}](https://payerworks.com/docs/organizations#delete-v1-org-members-id), [GET /v1/org/invitations](https://payerworks.com/docs/organizations#get-v1-org-invitations), [POST /v1/org/invitations](https://payerworks.com/docs/organizations#post-v1-org-invitations), [DELETE /v1/org/invitations/{id}](https://payerworks.com/docs/organizations#delete-v1-org-invitations-id), [POST /v1/org/join](https://payerworks.com/docs/organizations#post-v1-org-join), [GET /v1/org/keys](https://payerworks.com/docs/organizations#get-v1-org-keys). ## 10/20/2026: The account’s audit log What shipped: - GET /v1/audit-log lists every change to the account, newest first: keys, the webhook and its destinations, the notice address, providers, enrollment requests, tasks and documents, the SFTP user and its SSH keys, batch jobs, the organization and its members. - Each entry names who made the change (a key, a member, Payerworks, or Payerworks automatically), when, through which door, the object, and the fields that changed, by name only and never a value. - GET /v1/audit-log/export gives the same entries as a CSV file, at most 5,000 a call. Before: Nothing on the account said who changed what, or when. Now: Every key of the account, and every member with the role for it, reads one history of the account, each entry kept 365 days and never changed before then. Sandbox support: Test keys and live keys alike: every change a test key makes is recorded on its own account. Existing integrations: None: two new routes that only read. Routes: [GET /v1/audit-log](https://payerworks.com/docs/keys#get-v1-audit-log), [GET /v1/audit-log/export](https://payerworks.com/docs/keys#get-v1-audit-log-export). ## 10/20/2026: Sending claims to a payer, not offered while Payerworks is connected to no payer What shipped: - POST /v1/claims/submit answers 501 submit_not_offered with each of its five gates and whether it is open: sending switched on, a live key, a signed business associate agreement recorded for the account, a trading partner for the payer, and that partner switched on. Nothing is written or sent. - GET /v1/partners lists the trading partners a submission may go to, and is empty today. - Three event types for a live key’s own sends, made only from a partner’s answer to that key’s file: submission.file.acknowledged, submission.claim.acknowledged and submission.remittance.received. Before: There was no route for a live key to send a claim, and every route that writes a file said transmitted: false. Now: The route is there and shut. Every route that writes a file still says transmitted: false, and Payerworks is connected to no payer. Sandbox support: None: run the whole loop with POST /v1/sandbox/claims, which answers a 999, a 277CA and an 835 for invented claims. Existing integrations: None: two new routes, and three event types no key receives until it sends through a trading partner. Routes: [POST /v1/claims/submit](https://payerworks.com/docs/claims#post-v1-claims-submit), [GET /v1/partners](https://payerworks.com/docs/claims#get-v1-partners). ## 10/20/2026: Batch jobs, off until Payerworks turns them on What shipped: - A batch job runs up to 1,000 calls to one route from one file you upload to a signed form (50 MB at most), off the API’s ten-second clock, and its result is a file fetched by a signed link for 24 hours. - A job runs claim validation, 837P writing, the remittance, eligibility and claim status explanations, analytics, payment variance and claim tracking; POST /v1/eligibility/270 as a job writes one 270 of up to 7,500 questions. - job.completed and job.failed events, through the account webhook and the webhook destinations. - uploadJobFile in the JavaScript client. Before: Every call had to fit one request: 2 MB and ten seconds. Now: The same routes, many calls at a time. A job is the one part of the API that keeps what you send for a while: the file until the job finishes and the result for 24 hours, in storage of its own that keeps no earlier copy and is in no backup. Test keys only, 50 jobs a UTC day for an account’s keys together. Sandbox support: Off until Payerworks turns batch jobs on: until then every jobs route answers 501 jobs_not_offered. Then for test keys only, with invented data. Existing integrations: None: five new routes, and two new event types a webhook receives only once it makes a job. Routes: [POST /v1/jobs](https://payerworks.com/docs/jobs#post-v1-jobs), [GET /v1/jobs](https://payerworks.com/docs/jobs#get-v1-jobs), [GET /v1/jobs/{id}](https://payerworks.com/docs/jobs#get-v1-jobs-id), [POST /v1/jobs/{id}/cancel](https://payerworks.com/docs/jobs#post-v1-jobs-id-cancel), [DELETE /v1/jobs/{id}](https://payerworks.com/docs/jobs#delete-v1-jobs-id). ## 10/20/2026: A payer’s request for more information, and the 275 that answers it What shipped: - POST /v1/attachments/requests/explain reads a 277 request for additional information (005010X213) claim by claim: each LOINC code asked for, about which claim and line, by when, and the solicited 275 that answers it. - POST /v1/attachments/requests/check holds a solicited 275 to the request it answers before you send it. - POST /v1/attachments/275 writes a solicited 275 from those values: the request’s REF*EJ and submitter id, the payer’s response contact, and each attachment echoing its own requested code and service line. - Claim tracking counts a request no 275 answers as information requested, with its due day, and takes your solicited 275s as attachments. Before: A 275 could be written unsolicited, or under a trace you typed, and nothing read the payer’s request or said whether a claim was waiting on you. Now: The request is read and its answer is laid out, written and checked, all as public sources show these files, and every answer says so. Nothing is stored or sent. Sandbox support: In the claims sandboxes (837P, 837I and 837D), a member ID ending in RFAI is held for a document: a 277 request for additional information follows the 277CA, and the same claims sent again with the solicited 275 (attachments_275) are paid. Existing integrations: Additive: every new key appears only when a request or a 275 is in the call, and every earlier answer is the same, byte for byte. Routes: [POST /v1/attachments/requests/explain](https://payerworks.com/docs/documents#post-v1-attachments-requests-explain), [POST /v1/attachments/requests/check](https://payerworks.com/docs/documents#post-v1-attachments-requests-check), [POST /v1/attachments/275](https://payerworks.com/docs/documents#post-v1-attachments-275), [POST /v1/claims/track](https://payerworks.com/docs/acknowledgments#post-v1-claims-track), [POST /v1/sandbox/claims](https://payerworks.com/docs/claims#post-v1-sandbox-claims), [POST /v1/sandbox/claims/837i](https://payerworks.com/docs/claims#post-v1-sandbox-claims-837i), [POST /v1/sandbox/claims/837d](https://payerworks.com/docs/claims#post-v1-sandbox-claims-837d). ## 10/20/2026: The picture reads get 25 seconds What shipped: - The two picture reads run on a function of their own, with 25 seconds to read under the gateway’s 29. Before: A read had 8 seconds inside the API’s own ten, and the more accurate reader often missed it. Now: A read has 25 seconds; past them the answer is still 504 model_read_timed_out. Every other rule is the same: off until Payerworks turns a read on, test keys only, 100 reads a UTC day for an account’s keys together, no Idempotency-Key, nothing kept. Sandbox support: Off until Payerworks turns a read on, as before. Existing integrations: None: the same routes, answers and codes. Routes: [POST /v1/remittances/from-image](https://payerworks.com/docs/documents#post-v1-remittances-from-image), [POST /v1/payers/from-card](https://payerworks.com/docs/documents#post-v1-payers-from-card). ## 10/20/2026: A status page, published limits and a page per payer What shipped: - payerworks.com/status: whether the API, the sandbox, webhook delivery and the site answered, measured every five minutes from outside, with this calendar month’s counts and any incident, and an Atom feed of incidents. No payer is a part of it: Payerworks is connected to none. - payerworks.com/limits, and /payerworks/limits.json: every route family’s limits, each read from the constant the API refuses by when the page is built. - A page for each of the payer directory’s rows, linked from its letter page. - /.well-known/security.txt and a disclosure section on the security page; reports come through the one form and are answered by email. Before: None of these pages existed. Now: A measurement is said only with how many there were, for the month to date; a part not measured yet says so, never up. Sandbox support: The sandbox is one of the parts the status page measures, with one invented claim under Payerworks’ own test key. Existing integrations: None: no route changed. ## 10/20/2026: Docs by job, a changelog and a compatibility policy What shipped: - payerworks.com/docs: one page per job, each with the request, how to read the answer, troubleshooting and the code lists; five quickstarts; a page for coding agents; every error; this changelog and its feed. - Every docs page as markdown at /docs/.md, a docs llms.txt and the whole set as /llms-full.txt, and a Copy for agent button on each page. - A runnable example file for every family of routes, each run against the API in Payerworks’ own tests. - A written compatibility and deprecation policy for /v1. Before: One developers page listed every route, and /openapi.json held the contract. Now: The same routes, documented by job and as markdown, with examples you can run. Running them found five places where /openapi.json did not fit the API’s real answers, now corrected: claim tracking takes a claim with no reference, a timeline day and a claim’s paid total (in dollars and in cents) may be null, and GET /v1/sftp names its 403, as the two picture reads now do too. Sandbox support: Every quickstart runs on the sandbox payers with a test key. Existing integrations: None: no route changed. A client generated from /openapi.json may need regenerating to accept the nulls the API already answered. ## 10/20/2026: The platform and the documents What shipped: - Webhook destinations, up to ten a key, each with its own event types and long retries (seven attempts over about three days), its deliveries and every attempt listed. - An account’s keys: named keys, expiry, revocation, and rotation that keeps the key id; a notice address. - The MCP server hosted by the API itself at POST /v1/mcp. - The enrollment import, export and durations; the SFTP file drop where it is open. - PDFs drawn from what you send: the CMS-1500, a remittance, an eligibility answer, and Medicare’s two appeal forms filled in; a claim’s attachments as an X12 275. - Two picture reads (a paper EOB into a draft 835, a card into the payer and member ID), built and off until Payerworks turns them on. - Your own claim rules, a hospital standard charges file check, and the claims sandbox over simulated days. Before: One webhook a key, keys made only by the signup page or by Payerworks, the MCP server as a file to run yourself, and no documents. Now: 34 more routes, every one answered by the API itself and none in the browser’s engine. A route switched off answers 501 with a code ending in _not_offered, which the clients never retry. Sandbox support: The claims sandbox over simulated days (POST /v1/sandbox/claims/timeline). The documents run on any test file. The picture reads, when on, answer test keys only, with invented documents. Existing integrations: Additive. A claim that announces an attachment sent electronically (PWK02 EL) now carries a warning on validate naming the 275 that must follow; it is still valid. Routes: [GET /v1/webhook-destinations](https://payerworks.com/docs/events#get-v1-webhook-destinations), [POST /v1/keys](https://payerworks.com/docs/keys#post-v1-keys), [POST /v1/keys/{id}/rotate](https://payerworks.com/docs/keys#post-v1-keys-id-rotate), [POST /v1/mcp](https://payerworks.com/docs/keys#post-v1-mcp), [POST /v1/enrollments/import](https://payerworks.com/docs/enrollment#post-v1-enrollments-import), [GET /v1/sftp](https://payerworks.com/docs/sftp#get-v1-sftp), [POST /v1/claims/cms1500](https://payerworks.com/docs/documents#post-v1-claims-cms1500), [POST /v1/remittances/pdf](https://payerworks.com/docs/documents#post-v1-remittances-pdf), [POST /v1/eligibility/pdf](https://payerworks.com/docs/documents#post-v1-eligibility-pdf), [POST /v1/appeals/form](https://payerworks.com/docs/documents#post-v1-appeals-form), [POST /v1/attachments/275](https://payerworks.com/docs/documents#post-v1-attachments-275), [POST /v1/remittances/from-image](https://payerworks.com/docs/documents#post-v1-remittances-from-image), [POST /v1/payers/from-card](https://payerworks.com/docs/documents#post-v1-payers-from-card), [POST /v1/edits/rules/check](https://payerworks.com/docs/claims#post-v1-edits-rules-check), [POST /v1/price-transparency/validate](https://payerworks.com/docs/patient-money#post-v1-price-transparency-validate), [POST /v1/sandbox/claims/timeline](https://payerworks.com/docs/claims#post-v1-sandbox-claims-timeline). ## 10/19/2026: After the claim, eligibility tools, prior authorization and patient money What shipped: - Following up: when each open claim’s remittance is due, learned from your own payment history with how many paid claims it rests on. - Remittances after they arrive: duplicates by trace number, deposits matched to checks, an 835 split by payee or rendering provider, recoupments matched to the claims they take back, and published filing windows. - Analytics from your own files, every figure with its count and a floor before anything is called a pattern. - Eligibility tools: the next questions after a no-match, whether a payer answers a service type, which plan pays first, and whether a discovered coverage is the patient’s. - Prior authorization written as a 278 and its response explained, its sandbox, and Medicare’s published lists. - Patient estimates from a 271, a Good Faith Estimate, an equipment replacement window and the poverty guideline. Before: Claims could be written, tracked and explained, but nothing worked across many files after they were sent, and there was no 278. Now: 23 more routes. POST /v1/x12/parse names a 278 as its own kind. Sandbox support: The prior authorization sandbox (POST /v1/sandbox/authorizations), answering from the same payer as the eligibility sandbox. Existing integrations: Additive. A 270 that uses none of the new procedure fields is written exactly as before. Routes: [POST /v1/claims/follow-up](https://payerworks.com/docs/claim-status#post-v1-claims-follow-up), [POST /v1/remittances/duplicates](https://payerworks.com/docs/remittances#post-v1-remittances-duplicates), [POST /v1/remittances/reassociate](https://payerworks.com/docs/remittances#post-v1-remittances-reassociate), [POST /v1/remittances/split](https://payerworks.com/docs/remittances#post-v1-remittances-split), [POST /v1/remittances/recoupments](https://payerworks.com/docs/remittances#post-v1-remittances-recoupments), [GET /v1/filing-limits](https://payerworks.com/docs/remittances#get-v1-filing-limits), [POST /v1/analytics/summary](https://payerworks.com/docs/analytics#post-v1-analytics-summary), [POST /v1/remittances/variance](https://payerworks.com/docs/analytics#post-v1-remittances-variance), [POST /v1/eligibility/identity-retry](https://payerworks.com/docs/eligibility#post-v1-eligibility-identity-retry), [POST /v1/eligibility/coordination](https://payerworks.com/docs/eligibility#post-v1-eligibility-coordination), [POST /v1/authorizations/278](https://payerworks.com/docs/prior-authorization#post-v1-authorizations-278), [POST /v1/authorizations/explain](https://payerworks.com/docs/prior-authorization#post-v1-authorizations-explain), [POST /v1/estimates](https://payerworks.com/docs/patient-money#post-v1-estimates), [POST /v1/estimates/good-faith](https://payerworks.com/docs/patient-money#post-v1-estimates-good-faith). ## 10/19/2026: Claims written right, and the payer directory What shipped: - One published edit table, run by every claim route, with formatting repairs made on a copy and listed, and every check that could not run said with why. - Secondary and tertiary claims with their coordination of benefits, corrected and void claims planned, and every 837 read back to JSON. - The 837I and 837D writers and readers, with their sandboxes. - The payer directory: payers and plan programs from public federal files, with a payer ID only where the payer publishes it. Before: A claim was checked by a shorter list of rules, and the API wrote professional claims only. Now: Every claim route runs the same checks from one table, and the file is written from the repaired copy. Sandbox support: The 837I and 837D sandboxes (POST /v1/sandbox/claims/837i and /837d). Existing integrations: A claim that validated before may now be refused: the deeper checks require what the guides require, such as the submitter’s contact and the patient’s address. In a written 837P, PWK02 is now BM rather than AA, and REF*9F is written before REF*G1; a primary claim is otherwise written byte for byte as before. Routes: [GET /v1/edits](https://payerworks.com/docs/claims#get-v1-edits), [POST /v1/claims/837i](https://payerworks.com/docs/claims#post-v1-claims-837i), [POST /v1/claims/837d](https://payerworks.com/docs/claims#post-v1-claims-837d), [POST /v1/claims/correction-plan](https://payerworks.com/docs/claims#post-v1-claims-correction-plan), [GET /v1/payers](https://payerworks.com/docs/payers#get-v1-payers). ## 10/19/2026: Eligibility, claim status, denials, durable events and the SDKs What shipped: - The 270 written and every 271 explained; the 276 written and every 277 explained; each denial as the next step, and appeal letters from your facts. - Events recorded before they are sent, kept 30 days, listed and sent again; the Standard Webhooks headers beside Payerworks-Signature; Idempotency-Key on writes. - Claim tracking from the files you hold, and transaction enrollment with providers, requests, tasks and documents. - A JavaScript client, a Python client and an MCP server, generated from the route list. - One error catalog, and request ids in every refusal. Before: The API read 835s, 999s and 277CAs and wrote the 837P; an event was posted to the webhook, with one retry, and not kept. Now: Every core transaction is written or read, each in a sandbox. POST /v1/x12/parse answers a 277CA as kind 277CA, and refuses an interchange that holds two kinds of file. Sandbox support: The eligibility and claim status sandboxes, and the enrollment sandbox payer PWSANDBOX. Existing integrations: POST /v1/x12/parse answered a 277CA as kind 277 before this change. An interchange whose groups are of two kinds, which was read by its first group only, is now refused 422 mixed_functional_groups. Webhook receivers that check Payerworks-Signature keep working: the Standard Webhooks headers are added beside it. Routes: [POST /v1/eligibility/270](https://payerworks.com/docs/eligibility#post-v1-eligibility-270), [POST /v1/eligibility/explain](https://payerworks.com/docs/eligibility#post-v1-eligibility-explain), [POST /v1/claim-status/276](https://payerworks.com/docs/claim-status#post-v1-claim-status-276), [POST /v1/claim-status/explain](https://payerworks.com/docs/claim-status#post-v1-claim-status-explain), [POST /v1/denials/next-step](https://payerworks.com/docs/remittances#post-v1-denials-next-step), [POST /v1/appeals/letter](https://payerworks.com/docs/remittances#post-v1-appeals-letter), [GET /v1/events](https://payerworks.com/docs/events#get-v1-events), [POST /v1/claims/track](https://payerworks.com/docs/acknowledgments#post-v1-claims-track), [POST /v1/providers](https://payerworks.com/docs/enrollment#post-v1-providers), [POST /v1/enrollments](https://payerworks.com/docs/enrollment#post-v1-enrollments). ## 10/19/2026: Test keys by email, the claims sandbox, webhooks and the console What shipped: - A test key by email from the developers page, for invented data only. - The claims sandbox payer: a claim answered as a 999, a 277CA and an 835, by how its member ID ends. - Your account’s rate and its usage this month, and a signed webhook. - The console at payerworks.com/console. Before: A key was issued by Payerworks on request, and there was no sandbox. Now: A developer can get a test key and run a claim end to end alone. Sandbox support: The claims sandbox (POST /v1/sandbox/claims). Existing integrations: Additive. Routes: [POST /v1/sandbox/claims](https://payerworks.com/docs/claims#post-v1-sandbox-claims), [GET /v1/account](https://payerworks.com/docs/keys#get-v1-account), [PUT /v1/account/webhook](https://payerworks.com/docs/events#put-v1-account-webhook), [DELETE /v1/account/webhook](https://payerworks.com/docs/events#delete-v1-account-webhook), [POST /v1/account/webhook/test](https://payerworks.com/docs/events#post-v1-account-webhook-test). ## 10/18/2026: The Payerworks API What shipped: - Validate claims and write an 837P; read 835, 999 and 277CA files; explain a remittance and every acknowledgment rejection; codes in words. - Bearer keys, a rate per key, one error shape and a request id on every answer. Before: There was no API. Now: The engine as an API under /v1. It writes and explains files and transmits nothing. Sandbox support: None yet. Existing integrations: None: the first release. Routes: [GET /v1/health](https://payerworks.com/docs/keys#get-v1-health), [POST /v1/claims/validate](https://payerworks.com/docs/claims#post-v1-claims-validate), [POST /v1/claims/837p](https://payerworks.com/docs/claims#post-v1-claims-837p), [POST /v1/x12/parse](https://payerworks.com/docs/claims#post-v1-x12-parse), [POST /v1/remittances/explain](https://payerworks.com/docs/remittances#post-v1-remittances-explain), [POST /v1/acknowledgments/explain](https://payerworks.com/docs/acknowledgments#post-v1-acknowledgments-explain), [GET /v1/codes/carc/{code}](https://payerworks.com/docs/remittances#get-v1-codes-carc-code), [GET /v1/codes/claim-status/{category}](https://payerworks.com/docs/claim-status#get-v1-codes-claim-status-category).