You now get back a realistic mock 835 Electronic Remittance Advice (ERA) for claims submitted to Stedi’s test payer.
The mock ERAs mirror the type of electronic remittance you’d receive from payers in production. Each ERA contains the same information as if the test claim were paid in full.
For details, check out our announcement blog.
You can now tell which payers support vision coverage using the Stedi Payer Network or the Payers API.
For more details, see our announcement blog.
You can now submit claims as X12 EDI in the Stedi portal. Professional, dental, and institutional claims are supported. Previously, you could only submit claims as X12 using our X12 Claims API or SFTP.
For more information, see our announcement blog.
This entry refers to the Legacy Real-Time Eligibility Check JSON endpoint. We now have a redesigned version of that endpoint.
We strongly recommend the redesigned endpoint for new implementations. Its request and response shapes are more intuitive for both developers and AI agents, which speeds up integration. We still fix bugs in the legacy endpoint, but it's no longer under active development.
We’ve redesigned the benefits table for eligibility responses in the Stedi portal to make it faster and easier to read a patient’s benefits.
Benefits are now grouped by health plan. Each plan begins with its general limitations, followed by benefit details. The benefit details are organized by the Service Type Codes (STCs) and procedure codes from the payer’s response.
If present, benefits for STC 30 (Health Benefit Plan Coverage) and STC 35 (Dental Care) – the baseline STCs for medical and dental care – appear first.
The table displays information from the benefitsInformation objects in Stedi’s Legacy Real-Time Eligibility Check JSON responses.
Filter benefits
You can filter the table to quickly find benefits for a specific service, procedure, or coverage type – like a deductible or limitation. You can also filter by overage level and whether the benefit applies to in-network or out-of-network services.
For example, you can filter the table to only show individual deductibles for STC 3 (Consultation).
The table displays information from the benefitsInformation objects in Stedi’s Legacy Real-Time Eligibility Check JSON responses.
For more information, see our announcement blog.
The Batch Eligibility Check API endpoint now supports up to 10,000 eligibility checks in a single request. Previously, the limit was 1,000 checks per request.
For more information, see our announcement blog.
Required fields are marked with a red asterisk. For example, in the form, the insured's First and Last name is required.
The Stedi Payer Network now displays logos for select payers.
The Payer Network is Stedi's online payer list. The site lets you browse and search Stedi's supported payers for payer IDs, supported transaction types, and transaction enrollment requirements.
Logos make it easier to confirm you’ve found the right payer while browsing or searching.
The payer’s logo also appears on its detail page.
Logos in the Payers API
Stedi’s Payers API now returns the URL for a payer’s logo, when available. You can use the URLs to fetch payer logos for use in your own applications and interfaces.
The logo URL appears in the payer.avatarUrl field of the API response. The field is available for the Search Payer, List Payer, and Retrieve Payer endpoints.
Example:
{
"payer": {
"displayName": "Cigna",
"primaryPayerId": "62308",
"avatarUrl": "https://prod-payer-avatars.payers.us.stedi.com/HGJLR/avatar.png?v=1761841671464",
...
}
}We’ve redesigned the professional claim form in the Stedi portal to make it faster and easier to manually submit 837P professional claims.
The new layout mirrors the CMS-1500 (NUCC) Health Insurance Claim Form, the standard paper form for professional claims in the healthcare industry. If you’ve filled out a CMS-1500 before, the new form will look familiar.
To access the form, sign in to your Stedi account and go to https://portal.stedi.com/app/healthcare/claims/create. You can also open the form from the Stedi portal by going to Claims> Submit claim.
For more details, see our announcement blog.
We’ve expanded the Stedi Agent with two new conversational features:
Payer Finder: Ask questions about payers using conversational AI
Chats: A dedicated page for all your Stedi Agent conversations
You can use these tools to get answers to payer questions faster and easier.
For more information, see the announcement blog.
We’re replacing the SUBMITTED transaction enrollment status with two new statuses that show who needs to act next:
STEDI_ACTION_REQUIRED – Stedi needs to take action.
PROVIDER_ACTION_REQUIRED – You or the provider need to take action.
The SUBMITTED status is now deprecated. Any existing requests will keep the SUBMITTED status and use the previous status workflow until they're live, canceled, or rejected.
We've also clarified the PROVISIONING status to mean only thing: the request has been submitted to the payer.
These changes make it easier to see which requests need your attention. You can filter by the PROVIDER_ACTION_REQUIRED status in the Stedi portal or List Enrollments endpoint to see which requests require action by you or your provider. For example, using the endpoint:
https://enrollments.us.stedi.com/2024-09-01/enrollments?status=PROVIDER_ACTION_REQUIREDHow enrollment statuses work now
Requests submitted through the Stedi portal or a bulk CSV now start in the STEDI_ACTION_REQUIRED status. If you’re using the Create Enrollment endpoint, you can set the status to STEDI_ACTION_REQUIRED to start processing the enrollment.
This entry refers to the Legacy Real-Time Eligibility Check JSON endpoint. We now have a redesigned version of that endpoint.
We strongly recommend the redesigned endpoint for new implementations. Its request and response shapes are more intuitive for both developers and AI agents, which speeds up integration. We still fix bugs in the legacy endpoint, but it's no longer under active development.
The controlNumber request body field is now deprecated in the following JSON API endpoints:
The controlNumber field is now optional. We don't recommend specifying the controlNumber field in requests.
In the underlying X12, an interchange control number is used by payers to detect duplicate transaction submissions. Many payers enforce strict uniqueness rules for interchange control numbers.
When you use Stedi's JSON APIs – like those above – Stedi generates valid, unique interchange control numbers when we translate your JSON API request to X12. We ignore the controlNumber field in the JSON request.
For more information, see our Control numbers in X12 EDI blog.
You can now submit 837I institutional claims as X12 EDI using the Institutional Claims X12 API endpoint.
Most Stedi customers submit 837I claims using our JSON-based Institutional Claims endpoint. JSON is familiar and easy to work with. You can build an integration faster.
But if you already work with X12, converting to JSON wastes time. The new endpoint accepts X12 directly.
Previously, X12 submissions of 837I claims required SFTP. With SFTP, you have to wait for files to get errors or validation. With the API, you get instant responses. Development is faster, and debugging is easier.
For complete details, check out the Institutional Claims (837I) Raw X12 API reference.
Stedi integrated accounts and Stedi apps are now available. Together, this new set of capabilities allows end customers of Stedi’s Platform Partners to have Stedi accounts of their own.
Integrated accounts drastically reduce the amount of clearinghouse functionality that partners need to build themselves.
Integrated accounts
Integrated accounts are simplified Stedi accounts that are designed to be friendly to non-technical users. The more complex developer-focused functionality – such as configuring API access and webhooks, and viewing raw JSON payloads – has been removed.
Stedi apps
Integrated accounts can install Stedi apps, which are Stedi’s pre-built integrations to a growing list of third-party RCM, PMS, EHR, and other platforms.
Stedi apps allow providers to quickly connect their Stedi account to these external systems using preconfigured SFTP credentials and API keys.
They can also grant Stedi portal access for external support and implementation teams to assist with setup and ongoing support.
Learn more
See our announcement blog.
You can now correct and resubmit claims directly from the transaction detail page of any claim in the Stedi portal.
We’ve also made other UI improvements that make the portal’s Claims section simpler and faster to use. Here’s what’s new:
Streamlined list views and filters on the Transactions and Files pages help you find what you need, fast.
Cleaner detail pages for transactions and files put the most important information front and center.
For more information, see our announcement blog.
You can now run 276/277 real-time claim status checks in the Stedi portal.
You can submit a claim status check using the Stedi portal’s new Create claim status check page. You can access the page by clicking Claims > New claim status in the portal’s nav.
Previously, you could only run these checks using Stedi’s Real-Time Claim Status API.
For more information, check out the announcement blog.
You can now download documents for a transaction enrollment request directly from its details page in the Stedi portal. This includes documents signed by Stedi on your behalf if you use delegated signature authority.
For more information, see our documentation.
You can now filter results more precisely in the List Enrollments and List Providers API endpoints.
We’ve also updated the Enrollments page and Providers page in the Stedi portal to surface these filters.
List Enrollments endpoint
We’ve added new query parameters to the List Enrollments endpoint. You can use the parameters to filter by:
Partial term: filter lets you search across multiple fields at once.
Status: Filter by one or more enrollment statuses—such as DRAFT, SUBMITTED, PROVISIONING, LIVE, CANCELED, or REJECTED.
Provider details: Filter by NPI (providerNpis), tax ID (providerTaxIds), or name (providerNames).
Payer: Filter by payer IDs (payerIds).
Source: Limit results by how the enrollment was created: API, UI, or IMPORT.
Transaction type: Filter by transaction types, like eligibilityCheck, claimStatus, or claimSubmission.
Date: Filter enrollments by when they were created (createdFrom, createdTo) or when their status last changed (statusUpdatedFrom, statusUpdatedTo).
Import ID: If an enrollment was created through CSV import, filter by the returned importId.
Several of these query parameters accept arrays. You can include an array parameter more than once in the URL to filter by multiple values.
List Providers endpoint
The List Providers endpoint now accepts a filter parameter for searching by provider name, NPI, or tax ID. Filtering is case-insensitive and supports partial matches.
Updated filters in the Stedi portal
Alongside API improvements, we’ve updated the Stedi portal to surface these new filters on the Enrollments page and Providers page.
On the Enrollments page:
On the Providers page:
Update (September 2026): We updated this post for Agentic Discovery, which replaces the eligibility check recovery it originally described.
Now available in the Stedi portal, the Stedi Agent brings AI-powered automation to healthcare clearinghouse workflows, beginning with eligibility check recovery.
Use the Stedi Agent to recover failed eligibility checks. A Launch Agentic Discovery option appears next to each failed check. If recovery fails, the agent runs an insurance discovery check.
For more information, see our announcement blog.
Stedi now enriches most Blue Cross Blue Shield (BCBS) eligibility responses by automatically including the member’s home payer name and primary payer ID whenever possible.
This info appears in a related benefitsInformation.benefitsRelatedEntities entry in our JSON eligibility responses and in a 2120C or 2120D loop in X12 responses.
For more information, see our announcement blog.
Stedi is now e1 certified by the HITRUST for foundational cybersecurity.
HITRUST e1 Certification demonstrates that Stedi’s healthcare clearinghouse platform is focused on the most critical controls to demonstrate that essential cybersecurity hygiene is in place. The e1 assessment is one of three progressive HITRUST assessments that leverage the HITRUST Framework (HITRUST CSF) to prescribe cyber threat adaptive controls that are appropriate for each assurance type.