Changelog

You can now authorize Stedi to sign enrollment forms for you using delegated signature authority, eliminating over 90% 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.

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&coverageType=dental

For more details, see the blog.

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.

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.

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.

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 850+ 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 use the Claim Attachment API to send 275 claim attachments with Stedi. New API endpoints include:

• Create Claim Attachment (275) JSON

• Submit Claim Attachment (275) JSON

• Submit Claim Attachment (275) Raw X12

For some medical and dental procedures, payers want more documentation. Claim attachments show a service occurred or was needed.

The new API lets you upload a PDF or image file to Stedi. You can then use the API to send the file to a payer in a 275 transaction.

If you already generate X12 files, you can send 275 transactions directly using the Submit Claim Attachment (275) Raw X12 endpoint or through Stedi SFTP instead.

Not all payers accept EDI attachments. Before sending, check the Stedi Payer Network or the Payers API to see if your payer accepts 275 transactions for claim attachments.

For complete details, visit the Claim attachments docs.

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.

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:

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.

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."
  }
]

This new endpoint allows you to use a Stedi business identifier (the claim’s correlation ID) to retrieve the CMS-1500 PDF for submitted 837 professional claims.

1. Call the endpoint with the business identifier as a query parameter for the claim form PDFs you want to retrieve. The business identifier should be the claim’s correlation ID. You can find this value in the claimReference.correlationId property in the synchronous responses from the Professional Claims and Professional Claims Raw X12 endpoints.

2. Stedi returns an array of PDFs for all claims with the specified business identifier value. The PDFs are returned as a base64 encoded string. 

3. Decode the base64 string and save it to a file with a .pdf extension.

Visit the CMS-1500 PDF: Business Identifier API docs for complete details.

Test mode provides a separate test environment where you can simulate transactions in your Stedi account without PHI/PII and without sending any data to payers. 

In test mode, you can submit mock real-time eligibility checks and Stedi sends back a realistic benefits response so you know what kinds of data to expect in production. You can send mock requests for a variety of well-known payers, including:

• Aetna

• Cigna

• UnitedHealthcare

• National Centers for Medicare & Medicaid Services (CMS)

• Many more - Visit Eligibility mock requests for a complete list

After you submit a mock eligibility check, you can review all of the request and response details in Eligibility Manager. This includes a user-friendly benefits view designed to help you quickly understand the patient’s active coverage and payment responsibilities.

To access test mode in your account, toggle Test mode to ON. Visit the test mode docs for more details.

You can use Stedi’s fully-managed SFTP server to submit claims to payers and retrieve claim responses. Stedi SFTP is a great option if you have an existing system that generates X12 EDI files and you want to send them through the Stedi clearinghouse without an API integration.

Here’s how SFTP claims processing works:

1. Create both test and production SFTP users through the Healthcare page in Account settings. Test users can only send claims to Stedi’s test clearinghouse, which helps ensure you never accidentally send test claims to payers while you’re getting up and running.

2. Connect to Stedi's server and drop compliant X12 EDI claim files into the to-stedi directory. 

3. Stedi automatically validates the claim data. If there are no errors, Stedi routes your claims to the test or production clearinghouse.

4. Stedi places claim responses - 277 Claim Acknowledgments and 835 Electronic Remittance Advice (ERAs) - into the from-stedi directory in X12 EDI format. 

5. You retrieve claim responses from the SFTP server at your preferred cadence.

You can also configure Stedi webhooks to send claim processing events to your endpoint. This allows you to monitor for processing issues, confirm successful claim submissions, and get notified when new payer responses are available.

Visit the SFTP claim submission docs for complete details.

Developers and operations teams can now submit transaction enrollments to payers using bulk CSV import functionality. This allows you to submit hundreds of enrollment requests to Stedi in minutes. 

Here’s how it works:

1. Go to the Bulk imports page and click New bulk import.

2. Download the CSV template with the required fields. The upload page contains detailed formatting instructions. 

3. Complete and upload the CSV file containing enrollment information—one row equals one enrollment request for a specific transaction to a payer. 

4. Stedi checks the file for errors and notifies you of any issues. You can fix the errors and re-upload the file as many times as needed. 

5. Once you execute the import, Stedi automatically creates provider records and enrollment requests. 

6. When the import is complete, you can download a report that shows the status of each row in the CSV file to ensure all your enrollment requests were submitted successfully. You can also track the status of each new enrollment request through the Enrollments page.

7. The Stedi team will contact you with any additional information required for the enrollment and will let you know when it is live.

Visit the Stedi Payer Network to find out if a payer requires enrollment for a particular transaction type.