We just launched a redesigned JSON Real-Time Eligibility Check API endpoint as part of our 2026 Stedi Keynote earlier this month. Our legacy JSON Eligibility API endpoint mirrored the X12 eligibility response. Benefits for every plan and every benefit type land in one flat array of objects. Those objects share the same schema, but the fields used in each vary based on benefit type. Co-insurance uses a percentage. Deductibles and co-pays have a monetary amount. Our new endpoint groups benefits by health plan. Within each plan, it uses a different schema for each benefit type. Co-insurance requires a percentage. Deductibles require an amount. We also got rid of other X12 baggage. Instead of deciphering benefit type based on a code value (1 for active coverage, A for co-insurance), each benefit type has an easy-to-read array key. These changes make it easier for developers and AI coding agents, like Claude Code or Codex, to pick up the API quickly. You can read the announcement on our blog: stedi.com/blog/introducing-o… You can watch the keynote here: stedi.com/keynote

Cair Health is an agentic operating system for revenue cycle management (RCM) – the administrative work that turns a patient visit into a payment. Cair's agents check coverage, code visits from clinical notes, scrub claims, work denials, and post payments. Cair's platform carries more than 80 integrations. Those integrations let Cair's agents read encounters, notes, and claim data out of each customer's system, and write results back. The problem is that none of them could submit a claim to a payer. Cair's agents could retrieve, correct, scrub, and validate a claim, but they couldn't deliver the finished claim to a payer. Customers had to complete that step themselves. The handoff also meant Cair had less visibility into the claims lifecycle after submission. Cair couldn't retrieve the claim acknowledgments or Electronic Remittance Advice (ERAs) directly. If a customer wanted Cair's agents to work a denial, they had to feed that information back in. "Customers had to forward us their remittances," says Ishan Balakrishnan, co-founder of Cair Health. "If a claim was denied, it just showed up again a few weeks later. There wasn't a neat claims lifecycle we could follow." Cair integrated their agents with Stedi's JSON Claim Submission API. The Stedi Payer Network lets Cair submit electronic claims to the payers their customers already bill, using their existing payer IDs with no mapping required. Cair also uses Stedi's webhooks to get notified of new claim acknowledgments and ERAs. Cair's claims volume grew by 4.3x in their second month on Stedi. Two months later, their monthly claims volume had increased by 141x. Cair now submits tens of thousands of claims a month to 199 payers through Stedi, and payers accept 98% of them. "Now our agents follow the claim all the way to the payer's response," says Ishan. "There are no more customer handoffs or manual forwarding. Stedi lets us automate and track the entire claims workflow from submission to payment." Read the full case study: stedi.com/customers/cair-hea… To watch Cair Health in action, check out this clip from our June 2026 Platform Partner Demo Day: piped.video/watch?v=juTeGA9_…

StoriiCare is an Electronic Health Record (EHR) and system of record for adult day centers and community-based healthcare providers. EHRs are the software systems care providers use to manage patient records and clinical workflows. Care organizations across 40 US states and 13 countries use StoriiCare. Most providers that use StoriiCare deliver ongoing care. The same participants attend week after week, and most visits are reimbursable services. StoriiCare lets those providers keep the care record and the billing in one integrated system. But claim submission was still manual, and the legacy clearinghouse made it worse. Each customer exported their claims from StoriiCare and keyed them into the clearinghouse portal by hand. The portal was hard enough to use that StoriiCare trained every customer on it, then followed up when they got stuck. Every new customer meant the same clearinghouse setup and the same training again. As StoriiCare grew, claim submission became a bottleneck. StoriiCare switched to Stedi and built Stedi's APIs directly into its product, including the Professional Claims API for claim submission. Stedi also runs every claim through validation checks called claim edits before it reaches the payer, so centers catch errors up front instead of waiting days for a payer rejection. Stedi's Payer Network also lets StoriiCare reach payers the legacy clearinghouse couldn't, including the Veterans Affairs Community Care Network. StoriiCare now submits thousands of claims each month through Stedi, and payer acceptance rates have increased. Customers no longer need to access payer systems directly. They do everything from one place: StoriiCare. "Many of our centers serve veterans, and those claims used to be a dead end. With Stedi, we know we can reach the payers we need," says Mirko Jons, Head of Product at StoriiCare. "Our team spends less time getting customers set up and more time helping them get paid." Read the full case study: stedi.com/customers/storiica…

In case you missed it: Stedi now supports dental claims, attachments, and delivery tracking for paper claims. With paper claims, Stedi prints and mails a claim to any payer for you. You submit paper claims using the same APIs, SFTP, and portal forms you use for electronic claims. Previously, paper claims covered professional (CMS-1500) and institutional (UB-04) claims only. Dental claims weren't supported. Attachments weren't supported. And you only got one 277CA claim acknowledgment when Stedi forwarded the claim for printing. Nothing told you whether the claim reached the mail. Now, you can submit dental claims as paper claims using the ADA dental claim form. You can also send 275 claim attachments – X-rays or treatment plans, for example – with any paper claim. Stedi pairs the claim with the attachment, prints both, and mails them to the payer together. The Stedi portal's claims view now follows each claim through print and mail: staged, queued, printed, mailed, or failed. You get a 277CA when the claim is mailed, and another if the payer address fails validation. Every printed claim gets a PDF proof of the package that went out, so you can show a payer exactly what was sent. For more info, watch our 2026 Stedi Keynote or read the announcement blog. - Keynote: stedi.com/keynote - Announcement blog: stedi.com/blog/paper-claims-…

Stedi now has API endpoints that mirror the CMS-1500 paper claim form. The CMS-1500 – also called the HCFA form – is the standard paper form for professional claims. Every box on it has a number. Billers know those box numbers. Payers cite them in their own guides. And AI coding agents are trained on them. Previously, only the Stedi portal's claim form mirrored the CMS-1500. Our JSON 837P endpoint uses its own schema, so you had to map every box to one of our fields. The new endpoints group fields the way the form does. Our API reference even gives you the box number. There are three endpoints. One submits a claim, one validates a claim without sending it, and one retrieves a submitted claim in the CMS-1500 structure so you can correct it and resubmit. They're the same endpoints that power the Stedi portal's own CMS-1500 Claim Form. For more info, watch our 2026 Stedi Keynote or read the announcement blog. - Keynote: stedi.com/keynote - Announcement blog: stedi.com/blog/introducing-t…

You can now test an entire claims workflow in Stedi without sending a real claim to a payer or using production credentials. Previously, you could only submit test claims in production, and you had to mark each claim as a test. Attachments weren't supported. With Stedi's new end-to-end test mode, you can submit test claims with a test API key, test SFTP credentials, or directly in the Stedi portal. Every test claim returns a 277CA claim acknowledgment. Claims sent to the Stedi Test Payer return a test ERA that shows all service lines as paid, with the charge amounts you submitted. Test claims run through the same claim edits that apply in production. Attachments now work too. Read more about test mode for claims: stedi.com/blog/introducing-t… Watch the full keynote: stedi.com/keynote

EliseAI is a multi-channel AI platform that automates patient engagement for medical practices. Its voice AI agents answer incoming patient calls around the clock, with no hold time. More than 3,500 healthcare providers use EliseAI. Providers wanted EliseAI's voice agents to check a patient's insurance coverage before the patient completed intake or scheduled an appointment. Without a voice agent, front-desk staff usually verify a patient's insurance manually. They log in to a payer portal and search for the patient. Or they call the payer and wait on hold. But those options weren't viable for a voice AI agent. Payer portal logins are difficult to reliably automate for agents – the UI varies across payers. And calling a payer takes too long while a patient is on the phone. EliseAI needed a programmatic way for its agents to verify insurance in real time with the patient live on the line. EliseAI found its solution with Stedi's Real-Time Eligibility Check API. Stedi's eligibility checks return responses in 1-3 seconds, so patients aren't even aware a check has occurred. Every payer uses the same JSON request and response schemas, so EliseAI's team builds against one integration. "I don't trust an integration until it hits production. Stedi let me get there the same day," says Joshua Clark, founding software engineer at EliseAI. EliseAI now runs over 100,000 eligibility checks per month through Stedi, and 99% of those checks return a response before the call ends. "A patient calls once and leaves with an appointment they know is covered. Stedi is why we can promise that," says Ashim Vaish, Strategy and Operations Manager at EliseAI. Read the case study: stedi.com/customers/eliseai

More than one coverage in an insurance discovery response doesn't mean the patient has more than one active plan. Some payers return every plan they have on file – active, inactive, and coverage types you didn't ask about. And because discovery matches on demographics, some results may not be your patient at all. In those cases, it can look like the patient has two plans. You don't know which one to bill – and even when both are active, the response doesn't say which payer pays first. If you're a provider or biller working through a discovery response, Stedi's latest guide covers how to tell which coverage to use, and what to do when more than one is active. To learn more, read the blog: hubs.la/Q04xRg-S0

ICYMI: We announced Stedi Lockbox during our recent 2026 keynote. Stedi is all about electronic payer transactions, including ERAs and EFT payments. However, many payers still mail paper checks and paper remits, like Explanation of Payments (EOPs). Stedi Lockbox helps you track that paper in the Stedi portal. Stedi Lockbox gives you a mailing address for incoming physical mail. Stedi deposits any checks that arrive so you can reconcile them in Stedi Treasury, just like with EFTs. When your lockbox receives a paper remit or other mail, Stedi makes it available in your Stedi account as a PDF. Each PDF includes OCR text, so you can process the contents downstream. You can read more about Stedi Lockbox here: stedi.com/blog/introducing-s… You can watch the full keynote on YouTube or our site: stedi.com/keynote

SPRY is an AI-native Electronic Medical Record (EMR) and billing platform for physical therapy, occupational therapy, and speech therapy providers doing outpatient rehab. Their software helps more than 1,000 clinics schedule patients, document visits, and collect payment. Medicare patients make up a large share of most caseloads for outpatient rehab. SPRY ran eligibility checks for those patients through their previous eligibility vendor. That vendor didn't support eligibility checks to the Centers for Medicare & Medicaid Services (CMS), the government payer for Medicare. SPRY's providers had no quick and reliable way to check coverage or benefits for one of their most common payers. The vendor also post-processed eligibility responses from payers before passing them on. SPRY got the vendor's interpretation, never the payer's original. There was no way to tell what eligibility data the processing had dropped. The vendor pooled eligibility checks and claims under one shared rate limit. A spike in claim submissions could prevent SPRY's providers from running eligibility checks. SPRY switched to Stedi's JSON Real-Time Eligibility API. The Stedi Payer Network connects to 3,500+ payers, including CMS, so Medicare eligibility checks now run through the same API as every other payer. Stedi returns everything the payer sent in their response. Nothing is dropped. Eligibility checks also get their own concurrency limit, separate from the one used for claims. SPRY can now run eligibility checks with more than twice as many payers as before, and they expect to run 80,000 checks per month through Stedi. "With Stedi, we can grow our business without worrying about whether our eligibility vendor can keep up," says Henish Sutaria, Head of Finance at SPRY. "Now adding clinics is just adding clinics." Read the case study: stedi.com/customers/spry

We now have official Stedi SDKs for TypeScript and Python. An SDK gives developers – and now AI coding agents like Claude Code and Codex – the tools they need to build integrations in their preferred programming language. Before, we only offered REST APIs. If you wanted language-specific types, retries, or error handling, you had to write your own client. Now the SDKs do that work for you. You only need to write the parts that are specific to your product. Developers and coding agents can build more reliable integrations easily and quickly. You can find the SDKs on npm and PyPI: - npm: npmjs.com/package/@stedi/sdk - PyPI: pypi.org/project/stedi/ To learn more, read our announcement blog: stedi.com/blog/introducing-t…

You can now track a claim's full lifecycle – from submission to payer adjudication – in the Stedi portal's claims view. For example, you can see whether the payer denied a claim, or how much the payer paid. Previously, information in the claims view was derived solely from claim submissions and related 277CA claim acknowledgments. To get payment information for a claim, you had to jump from the claim's timeline to matching ERAs. Now, the portal displays information from those ERAs directly in the claims view. You can also now retrieve the same claim records using our Claims Lifecycle API endpoints. For more info, watch this clip from our 2026 Stedi Keynote: hubs.la/Q04xdm-w0 Or read the announcement blogs: - hubs.la/Q04xdm_g0 - hubs.la/Q04xdn190

We just released Agentic Discovery for the Stedi Agent during our 2026 Keynote. Agentic Discovery combines eligibility checks, automated check recovery, and insurance discovery into a single agentic workflow in the Stedi Agent. You start by running an eligibility check directly in the agent. If the check succeeds, the agent stops. If the check fails, the agent tries to recover it using Stedi's best practices. If recovery fails, the agent then runs an insurance discovery check. The agent handles the entire check-recover-discover flow for you. Watch the announcement from the keynote: hubs.la/Q04x7qlV0 Read our announcement blog post: hubs.la/Q04x7qlW0

When should you verify dental insurance eligibility? Many DSOs check 3–5 days before, the day before, and again on the day of service because coverage can change. Automation makes those repeat checks easier to manage. @stedi ▶️ Full webinar: mindbowser.com/webinar/webin… #DentalRCM

We announced several new features during our first-ever Stedi Keynote on September 9, 2026. Here's a recap: - Agentic Discovery – Combines eligibility checks, automated check recovery, and insurance discovery into a single agentic workflow in the Stedi Agent. - Stedi Treasury – Provision bank accounts, enroll for electronic funds transfers (EFTs), and receive payment from payers. - Stedi Lockbox – A mailing address for incoming physical mail. Stedi deposits any checks that arrive and scans the mail into PDFs. - OAuth Stedi apps – Stedi apps now support OAuth. Providers install an app in one click. App developers can register apps and open time-limited support sessions. - Claim lifecycle tracking, Stedi's headless RCM engine – Track a claim's full lifecycle, from submission to payer adjudication, in the Stedi portal's claims view. See denials and paid amounts directly. The new Claims Lifecycle API endpoints return the same claim records and can drive external applications. - Stedi TypeScript and Python SDKs – Stedi now has official TypeScript and Python SDKs, available from npm and PyPI. - CMS-1500 Professional Claim API endpoints – Submit, validate, and retrieve 837P professional claims through new JSON API endpoints that mirror the boxes on the CMS-1500 paper form. - Paper claims – Expanded support for CMS-1500, UB-04, and ADA dental claims and paper claim attachments for all claim types. Track each claim's print status with full 277CA acknowledgement support via webhook and SFTP, as well as PDF proofs in the Stedi portal. - End-to-end test mode – Test the entire claims workflow in test mode, using Stedi test API keys and test SFTP credentials. Simulate a claim's lifecycle end to end. - Redesigned JSON Real-Time Eligibility Check API – Our redesigned endpoint groups benefits by health plan and breaks the payer's benefit details out into separate typed objects, drastically reducing the amount of effort required to parse eligibility responses. Fully supported in Stedi’s new TypeScript and Python SDKs. Read the full recap on our blog: stedi.com/blog/2026-stedi-ke… To watch the full keynote, check out our YouTube channel: piped.video/watch?v=MxyCUNAr… --- Stedi is a financial technology company, not a bank. Banking services are provided by Grasshopper Bank, N.A., Member FDIC. The FDIC's deposit insurance coverage only protects against the failure of an FDIC-insured bank.

CombineHealth builds AI agents for revenue cycle management (RCM): the workflows a provider needs to follow to get paid by an insurance payer. One of those workflows is insurance verification. Payer portals were one way CombineHealth agents verified a patient's insurance. The agent logged in to the portal, pulled coverage details, then surfaced them back to the provider. Payer portals are built for front-desk staff, not agents. To get their agents structured data, CombineHealth's engineers found the request each portal makes when a person verifies insurance, then had their agents call those requests directly. But those requests depended on session cookies and headers that would eventually expire. When they did, someone would have to manually log back in to the portal. Every portal also returned a different response shape. Onboarding a provider with new payers meant new engineering work. CombineHealth moved insurance verification to Stedi's Real-Time Eligibility API. The API returns the same structured response for every payer, and most checks come back in 1-5 seconds. There are no cookies to refresh, so all they need is a production API key. They now run thousands of eligibility checks a month through Stedi. One hospital group using their agents verified insurance 80% faster. "Our engineers were spending hours every week patching portal integrations," says Sourabh Agrawal, co-founder and CEO of CombineHealth. "Now we don't even have to think about our payer infrastructure. Stedi handles that for us." Read the full case study: stedi.com/customers/combineh…

We're hosting our first-ever Stedi Keynote next Wednesday, September 9th at 1pm ET / 10am PT. Our founder and CEO, Zack Kanter, will walk through a set of major product announcements, plus a lightning round of smaller features. The pre-recorded announcements will run about 40 minutes, followed by live Q&A. Join us: stedi.com/keynote

Where does healthcare end and social work begin? In our latest podcast, Neil Batlivala, co-founder and CEO of Pair Team, explains why that line doesn't hold for Medicaid patients. If someone has no housing and no food, managing their diabetes is important – but it often isn't the first problem to solve. In this clip, he illustrates the point by explaining how Pair Team finds patients. It doesn't run ads. It partners with shelters, food pantries, libraries, Catholic Charities, and the Salvation Army. As he puts it, Pair Team wants to manage someone's diabetes – but "we have to earn the right to do it." To hear the rest of the conversation, check out our latest Understanding Healthcare podcast: piped.video/watch?v=_iwrtSAr…

We just launched our new Event Destination API endpoints. An event destination is a webhook URL that Stedi sends events to when something in your account changes. For example, if you're building an EHR, you can get events when transaction enrollments are complete. We already had endpoints for listing and retrieving events, but not for setting up the destinations themselves. You couldn't script the setup of event destinations for different environments. And you couldn't rotate secrets on a fixed schedule. With these new endpoints, now you can. You can create destinations from a deployment script, or rotate every secret with a scheduled job. Stedi app developers can use these endpoints to configure event destinations for their providers' accounts. Read our announcement blog: stedi.com/blog/introducing-e…