CAQH CORE has officially certified Stedi for real-time eligibility checks.
This certification confirms that our 270/271 transactions meet CORE’s strict standards for:
What data a 271 response must include
Standardized error messaging
System uptime and performance under real-world conditions
For more details, see our CORE certification blog.
You can now submit transaction enrollments to select payers in a single step.
Just submit an enrollment request using Stedi’s Enrollments API, UI, or a bulk CSV import. We do the rest.
One-click enrollment is available for 1,400+ payers. Check the Stedi Payer Network or Payer APIs to see which payers are supported.
To learn more, see our full blog.
Stedi now has a direct connection to Zelis, a multi-payer provider platform.
Many payers use Zelis as their primary way of delivering 835 Electronic Remittance Advice (ERA) files through clearinghouses to providers.
To receive ERAs from Zelis, providers must set up an account in the Zelis portal. This involves selecting a clearinghouse from a prepopulated list. Previously, providers using Stedi had to select an intermediary clearinghouse in order to receive ERAs.
With Stedi’s new direct Zelis connection, you can now choose Stedi from the list of integrated clearinghouses. Once set up, you’ll automatically receive ERAs from all Zelis-connected payers directly through Stedi.
To submit new enrollment requests, use the Enrollments API, UI, or a bulk CSV import. For Zelis-connected payers, we’ll instruct you to select Stedi as the clearinghouse in Zelis when needed.
If you previously submitted a Stedi enrollment for a Zelis-connected payer, you can log into Zelis and select Stedi as the clearinghouse to transition to Stedi’s direct Zelis connection without any interruption or downtime.
For details, see the blog.
Stedi has partnered with Anatomy, a modern healthcare lockbox and document conversion service, to help you turn paper explanations of benefits (EOBs) into standard 835 Electronic Remittance Advice (ERA) transactions.
Previously, providers receiving paper EOBs had to scan and manually enter payment data, slowing down posting and introducing errors. You can now use Anatomy to handle paper EOBs using your existing digital workflow.
Anatomy accepts paper or PDF EOBs and converts them into 835s. Anatomy then securely sends the 835s to Stedi on your behalf. In Stedi, you can enroll to receive 835s from Anatomy just like you would if they were a payer. You get the ERAs using the 835 ERA Report API or the from-stedi directory of your Stedi SFTP connection. You can use webhooks to get notified when new ERAs are available.
Anatomy is now listed as a supported payer in the Stedi Payer Network. For more details, see the blog.
You can now use the Search Payers API to programmatically search the Stedi Payer Network.
The API lets you search by the payer’s name, payer ID, or payer ID alias. The search supports fuzzy matching, so it returns close matches even if the provided payer name isn’t exact. You can further filter the results by supported transaction types, like dental claims (837D) or eligibility checks (270/271).
The following request searches for the “Blue Cross” payer name and filters for payers that support eligibility checks and real-time claim status.
curl --request GET \
--url https://healthcare.us.stedi.com/2024-04-01/payers/search?query=Blue%20Cross&eligibilityCheck=SUPPORTED&claimStatus=SUPPORTED \
--header 'Authorization: <api-key>'Visit the Search Payers API docs for complete details.
We’ve also updated the Stedi Payer Network UI to use the new API. You now get consistent search results across the UI and API.
You can now include claim attachments in API-based 837P professional and 837D dental claim submissions.
For more information, see the announcement blog.
You can now request up to 200 results per page when using the pageSize query parameter in the Poll Batch Eligibility Checks API. The previous limit was 10.
With the higher limit, you can retrieve larger sets of eligibility results with fewer API requests.
GET /2025-04-25/healthcare/eligibility/poll-batch?batchId=abc123&pageSize=200Visit our batch refresh checks docs for complete details about batch eligibility checks.
The Batch Eligibility Check (270/271) API now supports up to 1,000 eligibility checks per batch. Previously, batches were limited to 500 checks each.
The Batch Eligibility Check (270/271) API lets you submit multiple eligibility checks in a single request, which Stedi processes asynchronously. You can use batch checks to run periodic patient eligibility refreshes before appointments, preventing surprises and billing delays.
Visit our batch refresh checks docs for complete details about batch eligibility checks.
The 277 Claim Acknowledgment (277CA) indicates whether a claim was accepted or rejected and (if relevant) the reasons for rejection. You may receive multiple separate 277CAs for each claim you submit to Stedi. Typically, this includes:
277CAs from Stedi reflecting whether the claim was sent to the payer or rejected due to validation issues.
A 277CA from the payer indicating whether the claim was accepted or rejected.
The 277CA Report API now returns additional properties in the transactions.payers array that allow you to quickly determine whether the 277CA was sent by Stedi or the payer. The organizationName property contains the sender's name (such as STEDI INC, or CIGNA), and the entityIdentifierCodeValue property contains either Clearinghouse or Payer.
"payers": [
{
"entityIdentifierCode": "AY",
"entityIdentifierCodeValue": "Clearinghouse",
"etin": "117151744",
"organizationName": "STEDI INC"
}
]We also added this information to the top of the 277CA details view in the Stedi portal for easy access.
Visit our claim responses docs for complete details about interpreting and retrieving 277CAs.
Eligibility checks verify a patient's coverage with a specific payer. But what if you don't know the patient's insurance details or you're not sure whether they have coverage at all? Now, you can run an insurance discovery check to find a patient's active coverage using only their demographic data.
You may need to run an insurance discovery check when a patient provides outdated insurance details, doesn’t have their insurance card, or can’t provide insurance details in an urgent care situation. You may also want to use insurance discovery checks to simplify patient onboarding.
Here's how insurance discovery checks work:
Submit a request to the Insurance Discovery API with as much patient demographic information as possible to increase the chances of finding matching coverage. You'll also include information like the provider's NPI and the date of service, similar to an eligibility check.
Stedi uses the demographic information you provide to determine if the patient has active coverage with one or more payers. This process involves submitting real-time eligibility checks to supported payers to find a match.
When the insurance discovery check is complete, Stedi returns an array of potential active coverages along with subscriber details and complete benefits information.
There is no cost for limited insurance discovery checks while the API is in beta. If you are interested in pricing when the product is generally available, please contact us.
Visit our Insurance Discovery docs for complete instructions, example requests and responses, and more.