Changelog

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.

A Medicare Beneficiary Identifier (MBI) is a unique, randomly-generated identifier assigned to individuals enrolled in Medicare. You must include the patient’s MBI in every eligibility check you submit to the Centers for Medicare and Medicaid Services (Payer ID: CMS). When patients don’t know their MBI, you can use Stedi's eligibility check APIs to perform an MBI lookup using their Social Security Number (SSN) instead.

To perform an MBI lookup:

1. Construct an eligibility check request with the patient’s first name, last name, date of birth, and Social Security Number (SSN).

2. Set the tradingPartnerServiceId to MBILU. This is a special Payer ID that tells Stedi to perform an MBI lookup for the patient in addition to a standard eligibility check.

3. Stedi returns a complete benefits response from CMS with the patient's MBI in the subscriber object for future reference.

Visit our Medicare Beneficiary Identifier (MBI) lookup docs for complete details.

The view for 277CA Claim Status transactions includes the following improvements:

• Key claim details, including the patient account number and the claim value, are at the top for easy access.

• Claim Status codes are displayed with clear descriptions, and processing issues are flagged to help you quickly catch errors and understand what went wrong.

• Related transactions, including the original claim, are identified and linked.

• The transaction’s raw input and output are available for review and download. 

To check out the updated view, click any 277CA Claim Status transaction listed on the Stedi Transactions page.

You can now submit coordination of benefits (COB) checks through the Coordination of Benefits Check API for any of Stedi’s supported COB payers.

• You submit COB checks programmatically in developer-friendly JSON. The information required is similar to a standard eligibility check – the patient's first name, last name, DOB, and either member ID or SSN.

• Stedi synchronously returns summary information about each of the patient’s active health plans and whether there is coverage overlap. When there is coverage overlap, Stedi returns the responsibility sequence number for each payer (such as primary or secondary, if that can be determined).

Visit the Coordination of Benefits Check API documentation for full details, test requests and responses, and more.

You can now create test API Keys for development and integration testing. 

Test API keys allow you to conduct integration testing on specific Stedi APIs without sending data to partners or processing PHI or PII. You can generate production and test API keys from the API Keys page in your Stedi account.

At launch, test API keys support hitting the Real-Time Eligibility Check API with the mock requests we have available. We will add support for other APIs in the near future. All mock requests sent with a test API key are free for testing purposes and won’t incur charges in your Stedi account.

When a patient is covered by more than one health plan, you need to know which plan is primarily responsible for paying claims (coordination of benefits). You can now submit coordination of benefits (COB) checks in the Stedi UI to determine:

• If a patient is covered by more than one health plan

• Whether coverage overlap requires coordination of benefits

• Each payer’s responsibility for payment (primacy) in coordination of benefits scenarios

For each COB check, Stedi searches a national database of eligibility data from state and commercial payers. This database has 245+ million patient coverage records from 45+ health plans, ASOs, TPAs, and others, including participation from the vast majority of national commercial health plans. Data is updated weekly to ensure accuracy.

The response includes information about the patient’s active health plans, whether coordination of benefits is required, and the responsibility sequence number for each payer if available (such as primary or secondary).

To help reduce claim denials, we recommend coordination of benefits checks for all new patients with coverage through one of Stedi’s supported COB payers. Visit the Payer Network for a complete list.

Developers and operations teams can now submit enrollments one at a time or in batches through Stedi’s user-friendly Enrollments dashboard or modern Transaction Enrollment API. 

Both submission methods follow the same streamlined process:

1. Add provider: You add a new provider record with the information required for enrollment, including the provider's name, tax ID, NPI, and contact information.

2. Submit transaction enrollment request: You submit requests to enroll the provider with required payers, one for each transaction type. For example, you’d submit three separate requests to enroll a provider for 837P (professional) claims, 270 real-time eligibility checks, and 835 ERAs (claim payments). You can save requests in DRAFT status until you're ready to submit them to Stedi. Once you submit an enrollment request, its status is set to SUBMITTED, and it enters Stedi’s queue for processing.

3. Provisioning: Stedi begins the enrollment process with the payer and sets the enrollment status to PROVISIONING. Our team leaves clear instructions about what to do next, if required, and provides hands-on help as needed with additional steps.

4. Enrollment is Live: Once the enrollment is approved, the enrollment status is set to LIVE, and the provider can start exchanging the enrolled transactions with the payer.

You can find out if a payer requires enrollment for a particular transaction type in the Stedi Payer Network.

You can use Stedi’s new Dental Claims API to send 837D (dental) claims through the Stedi Clearinghouse:

• Dental Claims: Submit your claim in user-friendly JSON. Stedi translates your request to the X12 EDI 837D format and sends it to the payer.

• Dental Claims Raw X12: Submit your claim in X12 EDI format. This is ideal if you have an existing system that generates X12 EDI files and you want to send them through Stedi’s API.

Both endpoints return a response from Stedi in JSON format containing information about the claim you submitted and whether the submission was successful. Later, the payer will respond with Claim Acknowledgments (277CA) and the ERA (835), which you can retrieve using Stedi’s APIs.

Visit the Stedi Payer Network to find every supported payer for dental claims.

You can now use Stedi’s Batch Eligibility Check API to submit multiple eligibility checks in a single request for Stedi to process asynchronously.

You can submit up to 500 individual eligibility checks within a single batch, and you can submit as many batches as you need to process. After you’ve submitted a batch of eligibility checks, you can use the Poll Batch Eligibility Checks endpoint to retrieve the results.

We recommend using this new API to perform batches of eligibility checks, such as during periodic refreshes for a patient population or when running weekly eligibility checks for upcoming appointments. Asynchronous batch checks don’t count toward your Stedi account concurrency budget, allowing you to stage thousands of batch checks while continuing to send real-time eligibility checks in parallel.

You can use the new Institutional Claims API to send 837I institutional claims through the Stedi clearinghouse.

• Call the endpoint with a JSON payload.

• Stedi translates your request to the X12 EDI 837I format and sends it to the payer.

• The endpoint returns a response from Stedi in JSON format containing information about the claim you submitted and whether the submission was successful.

• Later, the payer will respond with Claim Acknowledgments (277CA) and the ERA (835), which you can retrieve using Stedi’s APIs.

You can now submit five new mock requests for dental benefits to the Eligibility Check endpoint, and Stedi returns mock eligibility responses you can use for testing. To send a mock request, you need a Stedi API key for authentication, and you must set the stedi-test header to true.

Try it now for Ameritas, Anthem Blue Cross Blue Shield of CA, Cigna, Metlife, and UnitedHealthcare.