> ## Documentation Index > Fetch the complete documentation index at: https://docs.maxcare.ai/llms.txt > Use this file to discover all available pages before exploring further. # Get ERA service line by ID > Returns a single ERA service line with its adjustments. Requires read:eras scope. ## OpenAPI ````yaml /openapi-v2.json get /era-service-lines/{id} openapi: 3.0.0 info: title: Max AI Public API description: API for third-party marketplace apps version: '2.0' contact: {} servers: - url: https://api.maxcare.ai/v2 security: [] tags: [] paths: /era-service-lines/{id}: get: tags: - ERA Service Lines summary: Get ERA service line by ID description: >- Returns a single ERA service line with its adjustments. Requires read:eras scope. operationId: EraServiceLinesPublicController_getEraServiceLine parameters: - name: id required: true in: path description: ERA service line ID schema: type: string - name: X-Organization-Id in: header required: true schema: type: string description: Target clinic organization ID responses: '200': description: Success content: application/json: schema: $ref: '#/components/schemas/GetEraServiceLineSuccessResponse' '400': description: Missing or invalid request parameter content: application/json: schema: $ref: '#/components/schemas/PublicApiBadRequestResponse' '401': description: Invalid or missing API key content: application/json: schema: $ref: '#/components/schemas/PublicApiUnauthorizedResponse' '403': description: Insufficient scope content: application/json: schema: $ref: '#/components/schemas/PublicApiForbiddenResponse' '404': description: Resource not found content: application/json: schema: $ref: '#/components/schemas/PublicApiNotFoundResponse' '429': description: Rate limit exceeded content: application/json: schema: $ref: '#/components/schemas/PublicApiRateLimitResponse' security: - api-key: [] components: schemas: GetEraServiceLineSuccessResponse: type: object properties: code: type: string description: Response code example: success data: $ref: '#/components/schemas/ExternalEraServiceLineResponse' required: - code - data PublicApiBadRequestResponse: type: object properties: code: type: string description: Error code example: bad_request message: type: string description: Human-readable error message example: '''id'' must be a valid UUID' trace_id: type: string description: Trace ID for debugging example: 550e8400-e29b-41d4-a716-446655440000 required: - code - message - trace_id PublicApiUnauthorizedResponse: type: object properties: code: type: string description: Error code example: unauthorized message: type: string description: Human-readable error message example: Invalid or missing API key trace_id: type: string description: Trace ID for debugging example: 550e8400-e29b-41d4-a716-446655440000 required: - code - message - trace_id PublicApiForbiddenResponse: type: object properties: code: type: string description: Error code example: forbidden message: type: string description: Human-readable error message example: Insufficient scope trace_id: type: string description: Trace ID for debugging example: 550e8400-e29b-41d4-a716-446655440000 required: - code - message - trace_id PublicApiNotFoundResponse: type: object properties: code: type: string description: Error code example: not_found message: type: string description: Human-readable error message example: Resource not found trace_id: type: string description: Trace ID for debugging example: 550e8400-e29b-41d4-a716-446655440000 required: - code - message - trace_id PublicApiRateLimitResponse: type: object properties: code: type: string description: Error code example: rate_limit_exceeded message: type: string description: Human-readable error message example: Rate limit exceeded. Maximum 1000 requests per 60 seconds. trace_id: type: string description: Trace ID for debugging example: 550e8400-e29b-41d4-a716-446655440000 required: - code - message - trace_id ExternalEraServiceLineResponse: type: object properties: id: type: string description: >- ERA service line ID. NOT DURABLE ACROSS ModMed's UNPOSTED -> POSTED TRANSITION. While a remit is unposted its lines are keyed by a composite key; when the posted feed lands, the sync HARD-DELETES the composite rows and re-inserts the same remit lines under allocation keys, with new ids. `eraClaimId` is re-keyed in the same sweep, so it is not a stable anchor either. THERE IS NO DELETION FEED: a deleted row does not reappear in the `updatedSince` stream and carries no tombstone, so a consumer that keys on this id keeps the stale row forever AND ingests its replacement — counting the same payer dollars twice. RECONCILE AT THE CLAIM OR BILL LEVEL: treat the lines under a given `claimId`/`billId` as a SET that is replaced wholesale — when any line for one of those reappears, delete every line you hold for it and re-insert what this endpoint returns, rather than merging row by row. Periodically re-pull each claim/bill you track, since deletions are invisible to the cursor. UNMATCHED LINES HAVE NO ANCHOR: when `claimId` is null there is no claim or bill to reconcile against, and `?billId=`/`?claimId=` cannot return those rows at all. Only a periodic pull with NO `billId`, `claimId`, `dateFrom` or `dateTo` filter can detect that one was deleted — `serviceDate` can be absent, so a date window is not exhaustive either. Scope the sweep with `matched=false` instead. example: a1b2c3d4-5678-4abc-9def-0123456789ab eraClaimId: type: string description: >- Parent ERA claim ID. Re-keyed by the same unposted -> posted sweep described on `id`; not a stable anchor. example: b2c3d4e5-6789-4abc-9def-0123456789ab claimId: type: string description: >- The claim this remit line was matched to. NULL has TWO causes and they are not distinguishable here: the payer paid something the EHR could not tie to a claim of ours (a genuinely unmatched remit line), OR the EHR did match it and that claim was later ARCHIVED — archived claims are excluded, the way the public claims API excludes them. Either way the dollars are real and the linkage is missing, so do NOT total `claimId: null` as "unmatched payer dollars": some of it is matched money on an archived claim. NOT COVERED BY THE `updatedSince` CURSOR: this field is derived by joining, and the cursor is the service line's own `updatedAt`, which does NOT change when the linkage does. A line that was unmatched when you synced it stays `null` in your copy after the EHR matches it, and a claim archived later keeps appearing. Re-pull matched-ness on a schedule rather than trusting the delta stream for it — and sweep WITHOUT `dateFrom`/`dateTo`, because `serviceDate` can be absent, so a date-windowed sweep is not exhaustive over the rows whose linkage you are re-checking. nullable: true example: c3d4e5f6-7890-4abc-9def-0123456789ab billId: type: string description: >- The bill behind that claim. NULL whenever `claimId` is null (both of its causes), when the matched claim carries no bill linkage, when the bill row has not synced yet, and also when that bill has been ARCHIVED — the public bills API never returns an archived bill, so publishing its id would hand you a link that 404s. Carries the same cursor caveat as `claimId`: it is join-derived, so archiving a bill does not re-touch the service line's `updatedAt` and your stored copy will keep a now-dead id until you re-pull. nullable: true example: d4e5f6a7-8901-4abc-9def-0123456789ab patientId: type: string description: >- The patient the ERA claim names, resolved through the ERA claim's own patient key rather than through `claimId`, so it can be present where `claimId` is null. Resolvable against `/patients/{id}`, which needs the `read:patients` scope — a key with only `read:eras` gets this id and a 403 on the lookup. EHR-DEPENDENT ON EXACTLY THE ROWS YOU WANT IT FOR. EzDerm takes the patient off the remittance itself, so an EzDerm line carries this even when unmatched. ModMed only ever learns the patient THROUGH a matched claim, so a ModMed line the EHR never matched has none — its 835 NM1 patient identity is not exposed by this API today, and such a line must anchor on `eraClaimControlNumber` instead. `patientId` AND `claimId` MOVE INDEPENDENTLY, in both directions: a line can report `claimId: null` beside a live `patientId` (a matched claim that was later archived keeps the patient key the match wrote), and a ModMed line can lose its `patientId` on a later sync while keeping its claim. Read each field on its own and re-pull both; neither implies the other. Carries the same cursor caveat as `claimId`: it is join-derived, and a later match does not re-touch this line's `updatedAt`. nullable: true example: e5f6a7b8-9012-4abc-9def-0123456789ab eraClaimControlNumber: type: string description: >- PARENT ERA CLAIM SCALAR (835 CLP01) — the PROVIDER's own claim control number as it appears on the remit: the value the practice sent on the 837 and the payer echoed back. This is the join key for a line whose `claimId` is null, because it comes off the remittance itself and is populated whether or not the EHR tied the payment to a claim of ours. On EzDerm it is the practice claim number (`providerClaimId`); on ModMed the 835 patient control number. NULL when the remit carried none. nullable: true example: '12345678' payerClaimControlNumber: type: string description: >- PARENT ERA CLAIM SCALAR — the PAYER's claim control number for the same claim (their id, not ours). Secondary join key, and the one to quote when calling the payer. NULL when the remit carried none. nullable: true example: '0000123456789' claimStatusCode: type: string description: >- PARENT ERA CLAIM SCALAR (835 CLP02) — the claim status code the payer reported. `22` is a REVERSAL of a previous payment: branch on this rather than inferring a reversal from a negative `paidAmount`, which also goes negative for take-backs that are not reversals. Passed through from the EHR verbatim, so treat it as an open value space rather than an enum. NULL when the remit carried none. nullable: true example: '1' claimStatusCodeDescription: type: string description: >- Human-readable form of `claimStatusCode`, as the EHR supplied it. Display only — never parse it and never branch on it: the two EHRs word the same code differently. nullable: true example: Processed as Primary eraClaimChargeAmount: type: string description: >- PARENT ERA CLAIM SCALAR, repeated on every line of that claim — do NOT sum it across lines. The EHR's claim-level total CHARGE, subject to the same source caveat as `eraClaimPaidAmount` — read that field before using any of the three. Distinct from this row's own `chargeAmount`, which is the one line's charge. NULL when not reported. nullable: true example: '13775.61' eraClaimPaidAmount: type: string description: >- PARENT ERA CLAIM SCALAR, repeated on every line of that claim — do NOT sum it across lines. The EHR's claim-level total PAID. NOT ALWAYS THE PAYER'S OWN CLP04 FIGURE, AND THE RESPONSE CANNOT TELL YOU WHICH YOU HAVE. Several writers fill this column on ModMed — the ERA sync from the remittance, and other paths from the practice's own billed/posted totals — and the last one to touch the claim wins. The same is true of `eraClaimChargeAmount` and `eraClaimPatientResponsibilityAmount`. The consequence is what matters: this figure can be DERIVED FROM THE SAME per-item amounts as the service lines beneath it, so it cannot serve as an independent check on them — a claim missing lines can still add up. Use it as the EHR's headline number for the claim, and reconcile line counts some other way. NULL when not reported — never render as $0.00. nullable: true example: '13669.70' eraClaimPatientResponsibilityAmount: type: string description: >- PARENT ERA CLAIM SCALAR, repeated on every line of that claim — do NOT sum it across lines. The EHR's claim-level PATIENT RESPONSIBILITY, subject to the same source caveat as `eraClaimPaidAmount`. As opposed to this row's own `patientResponsibilityAmount`. NULL when not reported. nullable: true example: '0.00' checkNumber: type: string description: >- ERA HEADER SCALAR, repeated on every line of every claim under this remit — do NOT sum anything by it without grouping. The check or EFT trace number (835 TRN02) the payment arrived under. TOGETHER WITH `checkDate` THIS IS REMIT IDENTITY: two lines under the same claim carrying different values here came from DIFFERENT payments, which is how you tell a claim's COMPLETE payment history from the tail of one — a reversal and a reissue with no original among them, say. Not guaranteed unique across payers. NULL when the EHR recorded none (common on keyed-in EOBs, where `isEra` is false). nullable: true example: EFT2601234567 checkDate: type: string description: >- ERA HEADER SCALAR — the date on the check/EFT this line was paid under. The field to ORDER a claim's remits by; `createdAt`/`updatedAt` order by when WE synced them, which is not payment order. NULL when the EHR recorded none. nullable: true example: '2026-07-08T00:00:00.000Z' isEra: type: boolean description: >- True when this line came from an 835 electronic remittance; FALSE when it came from a paper EOB keyed into the EHR, which lands in the same tables. EOB lines are real payer dollars and are NOT filtered out — hiding them would understate collections — but they are not 835 data, so branch on this rather than assuming every row is a remittance line. Null only if the parent payment record is missing the flag. nullable: true example: true payerName: type: string description: >- Payer who sent this remittance, taken from the ERA HEADER rather than from the matched claim. This is the only route to payer identity on a line whose `claimId` is null — the rows where the EHR failed to tie the payment to a claim of ours, and where the `/v4/claims` join is unavailable by definition. Same value-space as `payerName` on `/v4/claims`, so a consumer can group across the two resources, but do NOT group ON IT: one payer arrives under several spellings. Group on `payerCode`. NULL when the ERA carries no resolved payer record — never render it as 'unknown payer' dollars belonging to one bucket. DO NOT TREAT A CACHED VALUE AS DURABLE. This is join-derived: it resolves through the payer record the ERA header points at, and both that record and which record the header points at can change after this line was synced. Some of those changes do not re-touch the line's own `updatedAt`, which is what the `updatedSince` cursor filters on — so a delta walk MAY never re-deliver the row, and your stored copy silently keeps the old value. Re-resolve payer identity on a schedule, the same treatment `claimId` needs. (Deliberately no list of which changes are cursor-visible: it differs by sync path, and a consumer that relies on any such list is one refactor away from a stale cache.) nullable: true example: Blue Cross Blue Shield of Michigan payerCode: type: string description: >- The payer's own identifier (X12/EHR payer id) — the same field `/v4/claims` exposes as `payerCode`, and the better of the two to GROUP ON, since `payerName` splits one payer across its spelling variants. STABLE ACROSS ModMed's unposted -> posted re-key: it is the payer's identifier, not a row id, so unlike this line's `id` and `eraClaimId` it survives the delete-and-reinsert sweep. NULL when the ERA has no resolved payer record, or that record carries no code. STABLE IS NOT IMMUTABLE, and that matters precisely BECAUSE this is the field to group on: it can change after a line is synced, and a delta walk may never re-deliver the row to tell you (see `payerName`). A consumer grouping money by this field should re-resolve it periodically, or one payer's cohort silently splits across the old code and the new one with no signal on either side. nullable: true example: '00710' postedAmount: type: string description: >- PARENT ERA CLAIM SCALAR, repeated on every line of that claim — do NOT sum it across lines. Remit dollars on this claim already APPLIED to bills in the EHR ledger. This is what the EHR has DONE with the remit, not what the payer said: every other money field on this row is remittance truth, this one is ledger truth. ModMed reports it per claim; on EzDerm, which posts a whole check atomically, it is the claim's paid amount when the parent ERA is posted and 0 otherwise. NULL means not reported / not knowable (the ModMed unposted feed, or an EzDerm claim with no paid amount) — never render NULL as $0.00. nullable: true example: '6420.00' unpostedAmount: type: string description: >- PARENT ERA CLAIM SCALAR, repeated on every line of that claim — do NOT sum it across lines. Dollars belonging to this claim that are NOT YET APPLIED to bills; EMA labels it 'Not Posted'. This is the figure behind 'the payer paid and the EHR has not posted it'. MODMED CAVEAT — PAYMENTS ONLY. It does NOT include unposted CARC adjustments, which EMA reports as a separate 'Reason Codes Not Posted' figure derived client-side; we do not capture that second bucket. So on a ModMed row `unpostedAmount = 0` does NOT imply 'nothing left to do on this claim' — a claim can have fully-posted payments and still-unposted adjustments. Do not label this as plain 'Unposted' in a UI without that qualification. (EzDerm is unaffected: its adjustments post atomically with the check, so there is no separate bucket to miss.) NULL means not reported / not knowable — never render NULL as $0.00, because '$0.00 unposted' reads as 'fully posted, nothing outstanding', which is a claim we have no basis for on a row that never reported a number. nullable: true example: '0.00' omittedAmount: type: string description: >- PARENT ERA CLAIM SCALAR, repeated on every line of that claim — do NOT sum it across lines. Dollars deliberately EXCLUDED from the check total by a biller. A PARALLEL bucket, never a subtrahend of the two above: it distinguishes 'nobody applied this yet' from 'a biller decided this will never be applied'. ModMed sets it through EMA's 'Omit from Total' action on an unmatched remit line; on EzDerm it is always 0, which has no omit concept at all. NULL means not reported — never render NULL as $0.00. nullable: true example: '0.00' procedureCode: type: string description: Procedure code (CPT/HCPCS) nullable: true example: J3245 procedureDescription: type: string description: Procedure description nullable: true example: Injection, tildrakizumab, 1 mg modifiers: description: Procedure modifiers example: - JW type: array items: type: string serviceDate: type: string description: Service date (ISO 8601 instant) nullable: true example: '2026-02-10T00:00:00.000Z' billedUnits: type: string description: Units billed nullable: true example: '100.000' paidUnits: type: string description: Units paid nullable: true example: '100.000' chargeAmount: type: string description: Charged amount for this line nullable: true example: '12000.00' allowedAmount: type: string description: >- Allowed amount — the contracted price the payer recognises for this line. NULL means the remit did not report one; render NULL as unknown, never as $0.00. nullable: true example: '8420.00' paidAmount: type: string description: >- Amount the payer actually paid on this line. This is the remittance's own figure, per CPT, reported for BOTH EHRs — and unlike the bill line item's `paidAmount` it is PAYER-ONLY, where that field sums payer and patient payments together. Use this one for anything that means 'what the payer paid'. NULL means the remit did not report one; never render NULL as $0.00. A line can be re-paid or recouped later, which re-touches `updatedAt`. nullable: true example: '6420.00' deductibleAmount: type: string description: >- Deductible applied to this line. EZDERM ONLY IN PRACTICE: the ModMed ERA sync does not write this column, so it is structurally NULL on every ModMed line even when the remit reported a deductible. Do NOT compute patient responsibility by summing this with `coinsuranceAmount` and `copayAmount` — on ModMed that sum is 0 on a line the patient really owes. Use `patientResponsibilityAmount`, which is populated for both EHRs. nullable: true example: '2000.00' coinsuranceAmount: type: string description: >- Coinsurance applied to this line. EzDerm only in practice — see `deductibleAmount`. NULL on ModMed regardless of what the remit said; never render NULL as $0.00. nullable: true example: '0.00' copayAmount: type: string description: >- Copay applied to this line. EzDerm only in practice — see `deductibleAmount`. NULL on ModMed regardless of what the remit said; never render NULL as $0.00. nullable: true example: '0.00' patientResponsibilityAmount: type: string description: >- Total patient responsibility on this line. Reported by the remit directly when it carries a non-zero line-level figure; otherwise DERIVED as the sum of `adjustments[].patientResponsibilityAmount` across ALL of this line's adjustments, because many payers report the split only in the adjustments. Note that is every adjustment, NOT only the ones whose `carcGroup` is `PR`: ModMed merges the patient-responsibility amount onto an existing contractual (`CO`) adjustment row and only emits a standalone `PR` row when there is none to merge into, so filtering by `carcGroup === "PR"` and summing yields 0 on lines the patient really owes. So this does NOT always equal `deductibleAmount + coinsuranceAmount + copayAmount` — those three can all be null on a line that still reports patient responsibility. A margin figure that omits this overstates what the practice collected: the payer's paid amount is not the whole of what the line settles at. NULL means neither source reported anything — never render it as zero. nullable: true example: '2000.00' adjustmentAmount: type: string description: Total adjustment amount on this line nullable: true example: '3580.00' adjustments: description: >- Contractual/denial adjustments (CARC/RARC) explaining the gap between charge and paid type: array items: $ref: '#/components/schemas/EraAdjustmentInfo' createdAt: type: string description: When the record was created example: '2026-03-01T12:00:00.000Z' updatedAt: type: string description: >- When the record was last modified. NEVER NULL on this feed — the underlying column is NOT NULL with a default, so every row is reachable by the `(updatedAt, id)` cursor described on `updatedSince`. A cursored walk therefore cannot silently skip a row the way it would if this were nullable (a NULL fails `updatedAt >= cursor`, and a client cannot detect a row it is never sent). example: '2026-03-14T09:30:00.000Z' required: - id - eraClaimId - claimId - billId - patientId - eraClaimControlNumber - payerClaimControlNumber - claimStatusCode - claimStatusCodeDescription - eraClaimChargeAmount - eraClaimPaidAmount - eraClaimPatientResponsibilityAmount - checkNumber - checkDate - isEra - payerName - payerCode - postedAmount - unpostedAmount - omittedAmount - procedureCode - procedureDescription - modifiers - serviceDate - billedUnits - paidUnits - chargeAmount - allowedAmount - paidAmount - deductibleAmount - coinsuranceAmount - copayAmount - patientResponsibilityAmount - adjustmentAmount - adjustments - createdAt - updatedAt EraAdjustmentInfo: type: object properties: id: type: string description: >- Adjustment ID. NOT STABLE ACROSS SYNCS. ERA sync replaces a service line's adjustments wholesale (delete + insert) rather than updating them, so each re-sync assigns fresh ids. Because a re-synced line reappears in the `updatedSince` stream, keying your own records on this id will duplicate or orphan them; treat it as valid only within the response that returned it. Do NOT fall back to keying on the service line's `id` either — it is not durable across ModMed's unposted -> posted sweep (see that field). The only durable anchors here are `claimId` and `billId`; key on one of those plus `procedureCode` plus `carc`, and reconcile as described on `id`. example: e1f2a3b4-c5d6-4e7f-8a9b-0c1d2e3f4a5b carcGroup: type: string description: CARC group code (CO, PR, OA, PI) nullable: true example: CO carc: type: string description: Claim adjustment reason code nullable: true example: '45' carcDescription: type: string description: CARC description nullable: true example: Charge exceeds fee schedule/maximum allowable rarcs: description: Remittance advice remark codes on this adjustment example: - N130 type: array items: type: string adjustmentAmount: type: string description: Adjustment amount nullable: true example: '9820.00' patientResponsibilityAmount: type: string description: Portion of this adjustment that is patient responsibility nullable: true example: '0.00' required: - id - carcGroup - carc - carcDescription - rarcs - adjustmentAmount - patientResponsibilityAmount securitySchemes: api-key: scheme: bearer bearerFormat: JWT type: http description: Marketplace API key ````