The drchrono Billing API reads and writes the revenue side of an independent medical practice: line items, transactions, patient payments, eligibility checks, insurance authorizations and daysheet reports. Its contract treats those records unequally, and that is the most useful thing in it. A billing line item has a full lifecycle. A patient payment can only be created and read.
What ships
drchrono scores 77.8 on the Kin Score, in the exemplar band, and 40.0 on Agent Readiness, in the agent-ready band. The Billing API has 38 operations against https://app.drchrono.com, and 27 of them are GETs. There are six POSTs, two PUTs, two PATCHes and one DELETE. Its record carries an OpenAPI contract, an overlay, documentation, an API reference, a getting-started guide, authentication and webhook links, a Postman guide and six JSON Schemas. All of it sits under one OAuth 2.0 authorization-code scheme.
Money is append-only, and the contract shows it
| Resource | Create | Read | Update | Delete |
|---|---|---|---|---|
/api/line_items |
yes | yes | PUT, PATCH | yes |
/api/patient_payments |
yes | yes | no | no |
/api/patient_payment_log |
no | yes | no | no |
/api/line_item_deletions |
no | yes | no | no |
/api/transactions |
no | yes | no | no |
I checked the source definitions as well as this cut, and no update or delete on patient payments appears there either. So a charge can change, while a payment is a fact you add to and read back. Patient payments also get their own scopes, billing:patient-payment:read and billing:patient-payment:write, apart from billing:read and billing:write.
The deletion log is the part an integrator should copy. When a line item is deleted, /api/line_item_deletions records its original ID and the appointment it was attached to. A sync job can poll that with since and remove what it mirrored, without diffing the whole ledger. Many APIs let records vanish silently. This one leaves a tombstone.
The list endpoints that POST
Three resources use a two-step read: line_items_list, transactions_list and clinical_note_field_values_list. You POST your filters and get a 201 with a uuid and a status of In progress, Complete, Failed or Canceled, then GET the batch using that uuid. An agent reading methods alone would take those POSTs for writes. The generated phrasing overlay marks the POSTs as reads, which is the right call.
Where the contract falls short
The four daysheet reports (day_sheet_charges, day_sheet_credits, day_sheet_patient_payments, day_sheet_totals) declare no responses at all. They also require a scope named billing, which is not among the scopes the security scheme defines. /api/patient_authorizations lists no scopes in its security requirement. These look like gaps in the documents, and the record cannot say how the live API behaves. A code generator will still build from what the contract says.
Our side has a wart too. This cut comes from tagging, so a clinical-note batch endpoint sits in Billing. The provider record also says api_count: 2, counting its two published definitions, while the page lists seven APIs cut from them. Both numbers are defensible, and the page should say which one it means. That is ours to fix.
Takeaway
If you are writing to this API, model payments as immutable, sync deletions from the log, and hand-write the daysheet response types. Start at the drchrono Billing API page.