# Replace payer phone calls with Stedi > Phone calls to payers are slow and expensive. Stedi's APIs replace most calls with standard healthcare transactions. This guide walks the questions providers ask payers and the Stedi APIs that answer each. Published May 8, 2026 Updated Nov 9, 2026 Category: Guide When you need information from a payer, picking up the phone seems like the natural choice. Phone calls are flexible and need no setup. The catch is that calls are slow and labor-intensive, which makes them expensive. Most of what you pay for is hold time. At any real volume, the math stops working. Automating the calls doesn't always help. Some payers won't accept calls from voice AI agents. Stedi's APIs replace most calls with standard healthcare transactions. In most cases, you get the same information as a call in a few seconds, for pennies each. This guide walks through the most common questions providers ask payers and how Stedi answers each. ## Is the patient covered by insurance for this visit? Most providers check a patient’s insurance before a visit and before submitting a claim. An [eligibility check](https://www.stedi.com/docs/healthcare/intro-eligibility-checks) confirms that a patient has active insurance and returns their plan benefits. You can run eligibility checks using Stedi’s [JSON Eligibility API](https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check), [X12 API](https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-eligibility-raw-x12), [SOAP API](https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-eligibility-soap), or the [Stedi portal](https://www.stedi.com/docs/providers/providers-eligibility-checks). A successful response includes the plan's coverage status and dates. For example, in a response from our [Real-Time Eligibility Check JSON](https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check) endpoint: ```jsonc { "plans": [ { "benefits": { "statuses": [ { "dates": { "period": { "start": "2027-01-11" // Optional start date (duplicate of service.start) }, "service": { // Coverage window for this benefit "end": "2027-12-31", "start": "2027-01-11" } }, "service": { "definition": "Health Benefit Plan Coverage", "system": "STC", "value": "30" }, "status": "ACTIVE_COVERAGE" // Active coverage } ] } } ], "subscriber": { "dates": { "plan": { "end": "2027-12-31", // Plan end date "start": "2027-01-11" // Plan start date } }, ... }, ... } ``` For more tips, see [Active coverage and eligibility dates](https://www.stedi.com/docs/healthcare/eligibility-active-coverage-benefits#does-the-patient-have-coverage-for-the-requested-service) in our docs. ## What is the patient’s co-pay, deductible, or other benefits? An [eligibility check](https://www.stedi.com/docs/healthcare/intro-eligibility-checks) also returns cost-sharing information. If you’re using our [JSON Eligibility API](https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check), cost-sharing and most other benefits are in each plan’s [`benefits`](https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check#response.plans.benefits) object, grouped by benefit type: ```jsonc { "plans": [ { "benefits": { "coInsurance": [ { "dates": { "latestVisit": { "start": "2026-04-04" // Last service } }, "network": { "indicator": "OUT_OF_NETWORK" // Out-of-network only }, "percent": "0", // 0% co-insurance "service": { "definition": "Dental Care", "system": "STC", "value": "35" }, "serviceLimits": [ // 1 visit every 6 months { "delivery": { "period": { "qualifier": "MONTH", // Months "value": 6 // Every 6 months }, "quantity": { "qualifier": "VISITS", // Visits "value": "1" // 1 visit } } } ] } ], "coPayment": [ { "amount": "10", // $10 co-pay "network": { "indicator": "IN_NETWORK" // In-network only }, "service": { "definition": "Pharmacy", "system": "STC", "value": "88" } } ], "deductible": [ { "amount": "1000", // $1000 deductible "coverageLevel": "INDIVIDUAL", // Individual coverage "network": { "indicator": "IN_NETWORK" // In-network only }, "service": { "definition": "Health Benefit Plan Coverage", "system": "STC", "value": "30" }, "timePeriod": "CALENDAR_YEAR" // Calendar year } ], ... } } ], ... } ``` Each cost type has its own array, and the amount is either a dollar ([`amount`](https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check#response.plans.benefits.coPayment.amount)) or a percent ([`percent`](https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check#response.plans.benefits.coInsurance.percent)). Common types include: | **Benefit type** | **What it means** | **JSON Eligibility API response field to read** | | ---------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `coInsurance` | Co-insurance | `[percent](https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check#response.plans.benefits.coInsurance.percent)` (Percentage) | | `coPayment` | Co-pay | `[amount](https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check#response.plans.benefits.coPayment.amount)` (Dollar amount) | | `deductible` | Deductible | `[amount](https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check#response.plans.benefits.deductible.amount)` (Dollar amount) | | `outOfPocket` | Out-of-pocket max | `[amount](https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check#response.plans.benefits.outOfPocket.amount)` (Dollar limit) | For more codes and tips, see [Patient responsibility](https://www.stedi.com/docs/healthcare/eligibility-patient-responsibility-benefits) in our docs. ## Does this service require prior authorization? The eligibility response includes a prior-auth indicator per service type. If you’re using our [JSON Eligibility API](https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check), look at each benefit’s [`priorAuthIndicator`](https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check#response.plans.benefits.coInsurance.priorAuthIndicator) in the response, such as on a `coInsurance` entry: | `**priorAuthIndicator**` **value** | **What it means** | | ---------------------------------- | ------------------- | | `REQUIRED` | Prior auth required | | `NOT_REQUIRED` | Not required | | `U` | Unknown | ```jsonc { "plans": [ { "benefits": { "coInsurance": [ { "priorAuthIndicator": "REQUIRED", // Prior authorization is required for anesthesia "service": { "definition": "Anesthesia", "system": "STC", "value": "7" }, ... }, ... ] } } ], ... } ``` Some payers include prior authorization details as free-text notes. Look for key phrases like "prior authorization" or "preauthorization" in each benefit’s [`messages`](https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check#response.plans.benefits.coPayment.messages) field, such as on a `coPayment` entry. These notes can clarify or override the `priorAuthIndicator` value. ```jsonc { "plans": [ { "benefits": { "coPayment": [ { "amount": "20", // $20 co-pay "messages": [ "Prior authorization required for mental health visits after 6 sessions." ], "network": { "indicator": "IN_NETWORK" // Applies to in-network services }, "service": { "definition": "Mental Health", "system": "STC", "value": "MH" }, ... }, ... ] } } ], ... } ``` For more details, see [Is prior authorization required?](https://www.stedi.com/docs/healthcare/eligibility-network-status-authorization-referrals#is-prior-authorization-required) in our docs. ## Who is the patient’s payer? Providers need a patient’s insurance information to bill the payer. But patients often forget their cards, switch plans, or don't know who covers them. An insurance discovery check (also called coverage discovery) finds active coverage from demographic data the patient is likely to know: name, date of birth, address, and optionally SSN. You can run insurance discovery checks using Stedi’s [Insurance Discovery API](https://www.stedi.com/docs/healthcare/api-reference/post-insurance-discovery) or the [Stedi portal](https://www.stedi.com/docs/healthcare/insurance-discovery-ui). Discovery checks return a list of potential matches. Each match carries the same data as an eligibility check, including member ID and benefits. Treat each item as a candidate, not a confirmed match. Use the `confidence` object to flag low-quality results like last-name mismatches: ```jsonc { "status": "COMPLETE", "coveragesFound": 1, "discoveryId": "12345678-abcd-4321-efgh-987654321abc", "items": [ { "payer": { "name": "Aetna", ... }, "subscriber": { "memberId": "J9606211996", "firstName": "JOHN", "lastName": "DOE" }, "benefitsInformation": [ { "code": "1", // Active coverage ... } ], "confidence": { "level": "REVIEW_NEEDED", "reason": "This record was identified as a low confidence match due to a last name mismatch." } } ] } ``` Benefits come back in `benefitsInformation` objects. They contain the same benefits as the `plans` array in an eligibility check response, organized differently. For details, see [Eligibility response shapes](https://www.stedi.com/docs/healthcare/eligibility-response-shapes). ## Who is the primary payer? When a patient has more than one insurance plan, say a child covered by both parents’ health insurance, claims go to the primary payer first, then the secondary. Figuring out the order is called coordination of benefits (COB). You can use Stedi’s [Coordination of Benefits Check API](https://www.stedi.com/docs/healthcare/api-reference/post-coordination-of-benefits) to determine that order. The API response’s [`primacyDetermined`](https://www.stedi.com/docs/healthcare/api-reference/post-coordination-of-benefits#response.coordinationOfBenefits.primacyDetermined) field tells you whether the check resolved a primary payer. Each payer entry’s [`entityIdentifier`](https://www.stedi.com/docs/healthcare/api-reference/post-coordination-of-benefits#response.benefitsInformation.benefitsRelatedEntities.entityIdentifier) field indicates the payer order (primary, secondary, etc.). ```jsonc { "coordinationOfBenefits": { "coverageOverlap": true, "instanceExists": true, "primacyDetermined": true, // Was the primary payer determined? "classification": "CobInstanceExistsPrimacyDetermined" }, "benefitsInformation": [ { "code": "R", "name": "Other or Additional Payor", "serviceTypeCodes": ["1"], "benefitsRelatedEntities": [ { "entityIdentifier": "Primary Payer", // Primary payer "entityName": "CIGNA", ... } ] } ... ] } ``` Like discovery checks, COB checks return benefits in `benefitsInformation` objects. ## What’s the status of a claim? A claim is the bill that a provider sends to the payer after care. You can submit claims electronically using Stedi's [JSON Claim Submission API](https://www.stedi.com/docs/healthcare/intro-to-claim-submission#api-claim-submission), [X12 API](https://www.stedi.com/docs/healthcare/intro-to-claim-submission#api-claim-submission), [SFTP](https://www.stedi.com/docs/healthcare/intro-to-claim-submission#sftp-claim-submission), or, for [professional claims](https://www.stedi.com/docs/healthcare/submit-professional-claims#before-sending-claims), the [Stedi portal](https://www.stedi.com/docs/healthcare/submit-professional-claims-ui#cms-1500-claim-form). Electronic claim submission is instant, but [adjudication](https://www.stedi.com/docs/healthcare/resubmit-cancel-claims#pre-adjudication-vs-adjudication), where the payer decides if and what to pay the provider for a claim, can take days or weeks. In between, the payer sends asynchronous transactions to the provider’s clearinghouse as the claim clears each gate: a [claim acknowledgment](https://www.stedi.com/docs/healthcare/claim-responses-overview#277ca-claim-acknowledgment) when the payer accepts (or rejects) the claim for processing and a final [remittance](https://www.stedi.com/docs/healthcare/claim-responses-overview#835-electronic-remittance-advice-era) when it's paid or denied. A [real-time claim status check](https://www.stedi.com/docs/healthcare/check-claim-status) gets the current status of a claim at any stage of the process. You can run claim status checks using our [JSON Real-time Claim Status Check API](https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-claim-status), [X12 API](https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-claim-status-raw-x12), or the [Stedi portal](https://www.stedi.com/docs/healthcare/check-claim-status#manual-submission). The response includes two codes: a [claim status category code](https://x12.org/codes/claim-status-category-codes) for the broad state (accepted, rejected, pending, finalized) and a [claim status code](https://x12.org/codes/claim-status-codes) for a more specific status for the claim. Together, these codes show exactly where a claim stands with the payer. For example, in a [JSON Real-time Claim Status Check API](https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-claim-status) response for a paid claim: ```jsonc { "claims": [ { "claimStatus": { "statusCategoryCode": "F1", // Finalized/Payment - The claim/line has been paid. "statusCode": "65", // Claim/line has been paid. ... }, ... } ], ... } ``` Some status codes also require an [entity identifier code](https://www.stedi.com/docs/healthcare/claims-code-lists#entity-identifier) that names who or what the status refers to. For example: ```jsonc { "claims": [ { "claimStatus": { "statusCategoryCode": "A3", // Returned as unprocessable claim "statusCode": "164", // Entity's contract/member number "entityCode": "IL", // Insured or Subscriber ... }, ... } ], ... } ``` ## What did the insurer pay the provider for this claim? After adjudication, the payer sends the provider an [Electronic Remittance Advice (ERA)](https://www.stedi.com/docs/healthcare/claim-responses-overview#835-electronic-remittance-advice-era), which acts as a receipt for one or more claims. It tells the provider what the payer paid on each claim and why. ERAs aren't delivered on request. Payers send them asynchronously to the provider’s enrolled clearinghouse. To change that clearinghouse, you must complete ERA [transaction enrollment](https://www.stedi.com/docs/healthcare/transaction-enrollment) for the provider and payer. At Stedi, you can receive ERAs in three ways: - **Webhooks and APIs** [Set up a Stedi webhook](https://www.stedi.com/docs/healthcare/configure-webhooks) to listen for incoming ERAs, then retrieve the ERA using the [ERA Report API endpoint](https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-reports-835). - **SFTP** Pull X12 versions of ERAs as they arrive in the `from-stedi` directory of your Stedi [SFTP connection](https://www.stedi.com/docs/healthcare/submit-claims-sftp-connection). - **Stedi portal** Download ERAs from the [Stedi portal](https://www.stedi.com/docs/healthcare/receive-claim-responses#stedi-portal), alongside related [claim submissions](https://www.stedi.com/docs/healthcare/claims-view#claim-timeline) and [acknowledgments](https://www.stedi.com/docs/healthcare/claim-responses-overview#277ca-claim-acknowledgment). ERAs include [Claim Adjustment Reason Codes (CARCs)](https://x12.org/codes/claim-adjustment-reason-codes) that describe why a service or the entire claim was paid the way it was. [Remittance Advice Remark Codes (RARCs)](https://x12.org/codes/remittance-advice-remark-codes) provide additional details. For example, a [JSON 835 ERA Report](https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-reports-835) response: ```jsonc "paymentInfo": [ { ... "claimAdjustments": [ { ... "adjustmentReasonCode1": "161", // Claim-level Claim Adjustment Reason Code (CARC) for provider performance bonus "adjustmentReason1": "Provider performance bonus", ... } ], "serviceLines": [ { ... "serviceAdjustments": [ { ... "adjustmentReasonCode1": "B12", // Service-level CARC for missing documentation "adjustmentReason1": "Services not documented in patient's medical records.", ... } ], ... "healthCareCheckRemarkCodes": [ { "codeListQualifierCode": "HE", // Indicates use of a Remittance Advice Remark Code (RARC) "codeListQualifierCodeValue": "Claim Payment Remark Codes", "remarkCode": "M30", // RARC for missing pathology report "remark": "Missing pathology report." } ], ... } ] } ] ``` The ERA also carries the financial information providers need to reconcile claims and payments against bank deposits. For example, the ERA contains the check or Electronic Funds Transfer (EFT) number used for payment: ```jsonc { "transactions": [ { "financialInformation": { "checkIssueOrEFTEffectiveDate": "20190316", // Payment issue date "paymentMethodCode": "ACH", // EFT payment via ACH "totalActualProviderPaymentAmount": "1100", // Provider payment amount "creditOrDebitFlagCode": "C", // Credit ... }, "paymentAndRemitReassociationDetails": { "checkOrEFTTraceNumber": "71700666555", // EFT reference number ... }, ... } ], ... } ``` ## When to still call the payer Some payer phone calls can't be easily replaced. Exceptions to policy and questions about contract terms need a human on each end making a subjective decision. In other cases, the payer may not return all the details you need in standard transactions. For example, eligibility responses often list frequency limits for a procedure, like two cleanings per year or one MRI per six months, but not how many the patient has already used. To get that information, you need to call the payer or log in to their payer portal. Even those calls can be automated. Several [Stedi Platform Partners](https://www.stedi.com/platform-partners) offer voice AI agents that handle payer calls programmatically. Other Platform Partners offer browser agents that extract data from payer portals. Before you automate calls, check the payer's policies. Some payers don't accept calls from AI agents. ## Automate at scale Stedi lets you automate real-time eligibility checks and real-time claim status check at scale. To get started with Stedi, [sign up](https://portal.stedi.com/auth/sign-up-intent) for a free account. It takes less than two minutes. There's no credit card required.