Changelog

Introducing Stedi’s CAQH CORE SOAP endpoint for real-time eligibility

You can now run real-time eligibility checks using our CAQH CORE–compliant SOAP API endpoint.

Most Stedi customers use our Legacy Real-Time Eligibility Check JSON endpoint for real-time eligibility. But if you're already using CAQH CORE SOAP, this new endpoint is the fastest way to start running eligibility checks with Stedi.

The endpoint supports CAQH CORE Connectivity Rule vC2.2.0. We plan to support CAQH CORE Connectivity Rule vC4.0.0 as industry adoption increases.

For complete details, see our documentation.

Introducing the Stedi MCP server

Today, Stedi announces the release of its Model Context Protocol (MCP) server.

The MCP server gives AI agents plug-and-play access to Stedi’s Real-Time Eligibility and Search Payers API endpoints, along with built-in guidance for common errors. You can connect your agents without having to write integration code or copy documentation.

For more information, see the announcement blog and our documentation.

Introducing the Retrieve Payer API endpoint

You can now use the Retrieve Payer API endpoint to get a single payer record by its Stedi payer ID:

curl --request GET \
  --url https://healthcare.us.stedi.com/2024-04-01/payer/{stediId} \
  --header 'Authorization: <api-key>'

The endpoint returns the same payer information as our existing JSON-based Payer API endpoints: payer ID, name, payer ID aliases, transaction support, enrollment requirements, and more. Just for a single payer.

For more information, see the Stedi docs and the announcement blog.

Introducing the Stedi Platform Partners directory

You can now use the Stedi Platform Partners directory to find RCM, EHR, and practice management systems that use Stedi.

Many healthcare companies are looking for modern RCM solutions – and can’t or don’t want to build one themselves. The directory helps you find solutions that are powered by Stedi’s API-first clearinghouse rails.

For more information, see the announcement blog.

Introducing delegated signature authority for enrollment forms

You can now authorize Stedi to sign enrollment forms for you using delegated signature authority, eliminating over 95% of your team’s enrollment paperwork.

Delegated signature authority is available to all Stedi customers. To get started, reach out to Stedi support.

For more details, see the blog.

Introducing medical and dental coverage filters for the Payers API

You can now see whether a payer supports medical or dental transactions using the Payers API and Stedi Payer Network.

Every payer in the network now includes a coverageTypes field in responses from Payers API endpoints. For example, in JSON responses:

{
  "items": [
    {
      "displayName": "Blue Cross Blue Shield of North Carolina",
      "primaryPayerId": "BCSNC",
      ...
      "coverageTypes": ["dental"]
      ...
    }
  ]
}

If you’re using the Search Payers API endpoint, you can also filter by coverage type. Example:

GET /payers/search?query=blue+cross&coverageTypes=dental

For more details, see the blog.

Introducing CSV uploads for batch eligibility checks

You can now run batch 270/271 eligibility checks by uploading a CSV file in the Stedi portal.

Use the new Eligibility check batches page to run batch checks using a bulk CSV:

• Submit up to 1,000 checks per file.

• Run multiple files at the same time.

• Pull results from any batch using the Poll Batch Eligibility Checks API.

Track all batches – CSV or API – in real time, in one place.

For more details, see the blog.

Introducing the List Payers CSV API

You can now use the List Payers CSV API to get a full list of Stedi’s supported payers in CSV format:

curl --request GET \
  --url https://healthcare.us.stedi.com/2024-04-01/payers/csv \
  --header 'Authorization: <api-key>'

The CSV includes the same data as the Stedi Payer Network UI and other JSON-based Payer APIs:

• Payer IDs

• Transaction support flags

• Transaction enrollment requirements, and more.

For complete details, see the List Payers CSV API docs.

Introducing email notifications for transaction enrollment updates

When the status of a transaction enrollment request changes, Stedi now sends you an automated email.

No setup is needed. These email notifications replace our previous manual notification process.

If an enrollment requires action on your part, we’ll continue to reach out to you via Slack or email with next steps.

For more information, check out our related blog.

Stedi is now CAQH CORE certified

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.

Introducing one-click transaction enrollment

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,500+ payers. Check the Stedi Payer Network or Payer APIs to see which payers are supported.

To learn more, see our full blog.

Get ERAs from Zelis payers directly through Stedi

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.

Convert paper EOBs into 835 ERAs with Anatomy

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.

Introducing the Search Payers API

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.

Introducing claim attachments

You can now include claim attachments in API-based 837P professional and 837D dental claim submissions.

For more information, see the announcement blog.

Increased page size limits for polling batch eligibility checks

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=200

Visit our batch refresh checks docs for complete details about batch eligibility checks.

Larger batch sizes for 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.

New sender details in 277 Claim Acknowledgment reports

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.

Introducing Insurance Discovery: Find active coverage with a patient's demographic data

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:

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

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

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

835 ERA Reports: Claim adjustment reason and remittance advice remark descriptions

The 835 ERA Report API retrieves 835 Electronic Remittance Advice (ERA) transactions from Stedi in developer-friendly JSON. The ERA data now contains full Claim Adjustment Reason Code (CARC) and Remittance Advice Remark Code (RARC) descriptions, making it easier to interpret the payer’s response. 

CARC codes describe why a claim or service line was paid differently than it was billed. Now, adjustments objects for both the claim and specific service lines contain an adjustmentReason property with the full code description. The following example shows the adjustmentReason1 property within the transactions.detailInfo.paymentInfo.serviceLines.serviceAdjustments object.

"serviceAdjustments": [
  {
    "adjustmentAmount1": "21",
    "adjustmentReasonCode1": "131",
    "adjustmentReason1": "Claim specific negotiated discount.",
    "claimAdjustmentGroupCode": "CO",
    "claimAdjustmentGroupCodeValue": "Contractual Obligation"
  }
]

RARC codes provide additional explanations for adjustments or convey information about remittance processing. Now, transactions.detailInfo.paymentInfo.claimAdjustments.serviceLines.healthCareCheckRemarkCodes objects contain an additional remark property with the full code description. 

"healthCareCheckRemarkCodes": [
  {
    "codeListQualifierCode": "HE",
    "codeListQualifierCodeValue": "Claim Payment Remark Codes",
    "remarkCode": "M30",
    "remark": "Missing pathology report."
  }
]