Stedi

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 3 actions API key available

Stedi website Platform Documentation Capability data verified 2026-11-13

Tomorrow's appointments are pulled on an evening schedule

Agent reads each patient's payer and member ID

Search Payers resolves the payer name to a Stedi payer ID

Check Eligibility runs a 270/271 check for the visit date

Agent reads coverage, copay, deductible and auth flags

Copays and remaining deductibles posted for the front desk

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. 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 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. 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 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

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

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.

Start building with Stedi

Free plan, no card required. Connect in minutes.

Start Building Free Have us build it