--- title: "Stedi Integration" description: "Run real-time insurance eligibility checks (270/271) through Stedi's healthcare clearinghouse. Agents confirm active coverage, copays, deductibles and prior authorization flags before a visit, and look up payers by name or ID." url: https://flowrunner.ai/integrations/stedi date_modified: 2026-10-28T13:47:16-07:00 --- # Stedi [Healthcare](https://flowrunner.ai/integrations/category/healthcare) Run real-time insurance eligibility checks (270/271) through Stedi's healthcare clearinghouse. Agents confirm active coverage, copays, deductibles and prior authorization flags before a visit, and look up payers by name or ID. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 3 actions · API key · available [Stedi website](https://www.stedi.com/) · [Platform Documentation](https://www.stedi.com/docs/healthcare/send-eligibility-checks) · Capability data verified 2026-11-13 1. Tomorrow's appointments are pulled on an evening schedule 2. Agent reads each patient's payer and member ID 3. Search Payers resolves the payer name to a Stedi payer ID 4. Check Eligibility runs a 270/271 check for the visit date 5. Agent reads coverage, copay, deductible and auth flags 6. Copays and remaining deductibles posted for the front desk 7. Inactive coverage or a rejection goes to the desk lead ## What This Integration Enables Stedi is an API-first healthcare clearinghouse, and this connector asks it one question in a form a flow can act on: is this patient covered for this visit? Check Eligibility sends a real-time 270 eligibility request to the patient's payer and returns the full 271 response. It asks about general medical coverage by default, dental on request, or the pharmacy benefit with service type 88. Alongside it comes a summary to branch on: active coverage, plan and group, copays, coinsurance, deductibles, out-of-pocket amounts, prior authorization flags and any payer rejection. FlowRunner agents run that check wherever the practice needs it: the night before appointments, when a new patient completes intake, or before a procedure is scheduled. Search Payers and Get Payer turn the payer name on an insurance card into the right payer ID and show which payers need enrollment first. A pharmacy check confirms pharmacy coverage and sometimes returns pharmacy copays or the pharmacy benefits manager to contact. It does not price a specific drug, and this connector submits no prior authorization requests. All three actions only read. The decisions come after the answer, so when coverage looks wrong the agent stops and asks a person on Slack, email, WhatsApp or phone before anyone tells a patient anything. ### Without FlowRunner **Portal checks one by one**: Staff log into each payer's portal and look up patients the day before, as time allows **Surprises at check-in**: An inactive policy or an unmet deductible is found when the patient is standing at the desk **Prior auth found late**: A service that needed prior authorization is noticed after the visit is already booked ### With FlowRunner **Every visit checked**: Each scheduled patient's coverage is checked against the payer before the day starts **Front desk briefed**: Copays and remaining deductibles are ready before the patient arrives **Flags raised early**: Prior authorization flags and payer rejections reach a person while there is still time to act ## Use Case Scenarios ### Night-before eligibility for every appointment Each evening the flow pulls tomorrow's appointments from the practice's EHR, such as [Healthie](https://flowrunner.ai/integrations/healthie). For each patient the agent reads the payer and member ID on file and calls Check Eligibility for the visit date. A check can take up to two minutes while the payer answers, and the step waits for it. Active coverage produces a line in the front desk's sheet in [Google Sheets](https://flowrunner.ai/integrations/google-sheets) with the copay and remaining deductible. Anything else goes to a person, with the payer's response attached. ### New patient intake from an insurance card A new patient completes intake and the card shows a payer name, not an ID. The agent calls Search Payers, which matches names, payer IDs and aliases loosely, and filters to payers that support eligibility checks. It uses Get Payer to confirm the match and see whether the payer requires enrollment. Then it runs Check Eligibility. When the search returns more than one plausible payer, the agent does not guess. It asks the intake coordinator which one is on the card. ### Prior authorization paperwork routed before booking A specialist's office schedules procedures from referrals. Before a procedure is booked, the agent runs Check Eligibility and reads the prior authorization flags for that service. When a flag is set, the agent creates a task in the practice's EHR for the authorization coordinator, with the payer, the plan and the referral attached. The procedure is offered to the patient only after the coordinator confirms the authorization is in hand. The authorization itself is filed outside this connector, which checks coverage and does not submit requests. ### Pharmacy benefit check for a specialty referral A specialty pharmacy receives a referral for a self-administered specialty drug, and the patient is built in [WellSky CareTend](https://flowrunner.ai/integrations/wellsky-caretend). The agent runs Check Eligibility with service type 88 for the pharmacy benefit, alongside the general medical check when the therapy may be billed to the medical side. Active pharmacy coverage, with the PBM named when the payer returns it, goes onto the order as the primary payer. The check says nothing about whether this drug needs prior authorization, so the insurance coordinator decides that before the order leaves intake. ## Human-in-Loop Highlight The gate is on what an inactive result means. Stedi returns payer rejections as data rather than errors, and a rejection often says more about the request than about the patient. A wrong member ID, a payer matched loosely by name, or a policy that changed at New Year all come back looking like no coverage. An agent that read that as "uninsured" might cancel the visit or tell the patient to pay in full. So the agent stops and asks the front desk lead in Slack: "Check Eligibility for Dana Price, visiting Dr. Ahmed at 9:30 tomorrow: the payer rejected the request, member ID not found. Search Payers matched 'Blue Cross' to two payers and I used the first. Call the patient for a new card, retry with the other payer, or keep the visit as booked?" The lead decides, and nobody tells the patient anything until then. This is [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) on an ambiguous answer, before it turns into a conversation with a patient. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via Slack Human decides Agent resumes with decision ## Agent Capabilities 3 actions ### Eligibility 1 - **Check Eligibility** Runs a real-time insurance eligibility check (270/271) with the patient's payer and returns the full response plus a summary to branch on: active coverage, plan and group, copays, coinsurance, deductibles, out-of-pocket amounts, prior authorization flags and any payer rejection. Asks about medical coverage by default, or the pharmacy benefit with service type 88. Used before visits, at intake, and before scheduling procedures or dispensing. ### Payers 2 - **Search Payers** Searches Stedi's payer network by name, payer ID or alias, loosely and ignoring case, optionally only payers that support eligibility checks. Returns each payer's IDs and supported transactions. Used to turn the payer name on an insurance card into the right ID. - **Get Payer** Reads one payer's record by its Stedi payer ID: names, payer IDs and aliases, coverage types, operating states, supported transactions and enrollment requirements. Used to confirm a match and to see whether a payer needs enrollment before checks will work. ## Frequently asked questions ### What can FlowRunner do with Stedi? FlowRunner agents can run Check Eligibility, Search Payers, and Get Payer in Stedi. ### Does connecting Stedi to FlowRunner require OAuth? No. Stedi connects to FlowRunner with an API key, no OAuth flow required. ### Can Stedi trigger a FlowRunner workflow automatically? Stedi doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Stedi?** This integration exposes Stedi to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. ## Need a custom Stedi automation? Our team can build it for you. Tell us the process. Our implementation team at Midnight Flow builds it around how you work, tests it on your real data, and keeps it running, in your own FlowRunner workspace. [Have us build it](https://midnightflow.ai/packages/custom?utm_source=flowrunner.ai&utm_medium=referral&utm_campaign=general&utm_content=integrations.aside&utm_term=stedi) --- Markdown version of https://flowrunner.ai/integrations/stedi. Site index: https://flowrunner.ai/llms.txt