Changelog

Stedi

Healthcare

EDI platform

API Reference

Get started

Log in

List Enrollments

The Payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list.

The payer's name, such as `Cigna` or `UnitedHealthcare`.

The Stedi-assigned identifier for the provider.

The provider's name, such as `Example Dental Associates, LLC`.

Whether 270 Eligibility Checks are included in the enrollment.

eligibilityCheck

Whether 276 Claim Status Requests are included in the enrollment.

claimStatus

Whether 837P Professional Claims are included in the enrollment.

professionalClaimSubmission

Whether 837I Institutional Claims are included in the enrollment.

institutionalClaimSubmission

Whether 837D Dental Claims are included in the enrollment.

dentalClaimSubmission

Whether 835 Electronic Remittance Advice (ERAs) are included in the enrollment.

claimPayment

The status of the enrollment. You can submit enrollments with either `DRAFT` or `SUBMITTED` status. The default is `DRAFT` if you don't include a status in the request. Once an enrollment is set to `SUBMITTED` status, only Stedi can set or update this property.

The date and time when the enrollment was created within Stedi.

The Stedi-assigned identifier for the enrollment.

Information about the payer the provider is enrolling with.

Information about the provider enrolling with the payer.

The status of the enrollment.
  - `DRAFT` - You are still editing the record and it has not been submitted to Stedi.
  - `SUBMITTED` - You have successfully submitted the request and it is in Stedi's queue for review.
  - `PROVISIONING` - Stedi has begun the process of completing the enrollment with the payer.
  - `LIVE` - The enrollment process is complete, and the specified provider can begin exchanging the listed transaction types with the payer.
  - `REJECTED` - The payer rejected the enrollment. Common reasons for rejection include incorrect details in the request and that the provider is not credentialed with the payer. Customer support will contact you with reasons for rejection and next steps.
  - `CANCELED` - The enrollment has been terminated per customer or provider request.

The date and time when the enrollment was submitted. If the enrollment is in draft status, `submittedAt` is not present. When the enrollment transitions from draft to submitted, `submittedAt` will be updated to the submission time. If the enrollment was created and submitted immediately, `submittedAt` will be equal or close to `createdAt`.

The type of transactions included in the enrollment.

The date and time when the enrollment was updated.

Describes one specific validation failure for an input member.

A detailed description of the validation failure.

A JSONPointer expression to the structure member whose value failed to satisfy the modeled constraints.

httpApiKeyAuth

A standard error for input validation failures.
This should be thrown by services when a member of the input structure
falls outside of the modeled or documented constraints.

The server response when the authorizer failed to authenticate the caller.

The server response for authorization failure.

The server response when an unexpected error occurred while processing request.

Automate transactions with the only API-first clearinghouse

Stedi Healthcare

Supported payers

Transaction enrollment

Overview

Real-time eligibility checks

Eligibility checks

Batch refresh checks

Troubleshooting

Eligibility troubleshooting

Interpret benefit response

Code lists

Eligibility code lists

Coordination of benefits checks

Coordination of benefits (COB) checks

Eligibility Manager

Professional claims

Submit professional claims

Dental claims

Submit dental claims

Institutional claims

Submit institutional claims

Claims code lists

Enhanced validation

Enhanced claim validation

Check claim status

Get and correlate 277s and ERAs

Retrieve and correlate responses (277s and ERAs)

Configure webhooks

Configure webhooks for claim responses

Platform overview

EDI platform overview

Gather requirements

Integration steps

Configuration overview

Partnerships

Connections overview

Choosing a connection type

Stedi SFTP/FTPS

Stedi SFTP/FTPS Connections

Remote SFTP/FTPS

Remote SFTP/FTPS Connections

Buckets

Bucket Connections

Transaction settings

Acknowledgments

Guides overview

What is an EDI guide?

Import guides

Import Stedi Guides

Advanced: Build guides

Advanced: Build Stedi guides

Share public guides

Public Guides

EDI settings

File processing overview

Parse EDI

Create outbound transaction

Customize the envelope

Customize the ISA and GS headers

Overview - Transform Guide JSON

Guide JSON format

Transformation approaches

Choose a transformation approach

Configure

Fragments: Split transactions into smaller chunks

Inbound files

Split inbound EDI files with fragments

Outbound files

Generate outbound EDI files with fragments

Monitor transactions

Events

Events types and structure

Webhooks overview

Error handling and limitations

Webhooks error handling and limitations

Mappings overview

Mappings - Transform JSON

Invoke

Invoke mappings

Limits

Mappings limits

Destinations overview

Configure destinations

Destinations error handling and limitations

Generate test files

Generate test files in your browser

Failures and retries

What is EDI?

What is an element?

What is an element in X12 EDI?

Elements - Requirements

Element Requirements in X12 EDI

Elements - Data types

Element data types in X12 EDI

Relational conditions

Relational conditions in X12 EDI

What is a segment?

What is a segment in X12 EDI?

Segments - Requirements

Segment requirements in X12 EDI

Segments - Repetition

Segment repetition in X12 EDI"

Glossary

HIPAA

X12 HIPAA

Accounts and billing

Acceptable Use Policy

Cookie Notice

Customer Agreement

Privacy Notice

Service Terms

Site Terms

Trust Center

Support

List Payers

Create Provider

Create Enrollment

Provider

Enrollment

List Providers

Update Provider

Update Enrollment

Delete Provider

Delete Enrollment

Real-Time Eligibility Check

Real-Time Eligibility Check Raw X12

Batch Eligibility Check

Poll Batch Checks

Poll Batch Eligibility Checks

Testing: Send mock requests

Eligibility mock requests

Professional Claims

Professional Claims Raw X12

Dental Claims

Dental Claims Raw X12

Institutional Claims

277CA Report

 NUCC 1500 PDF

NUCC 1500 Claim Form PDF

Real-Time Claim Status

Real-Time Claim Status Raw X12

835 ERA Report

This endpoint generates and delivers fully-formed EDI files containing a single transaction. It is the simplest way to generate EDI with Stedi.

Outbound transaction

Create Outbound Transaction

This endpoint stages a transaction for outbound delivery.

Stage transactions

This endpoint generates and delivers a fully-formed EDI file containing the staged transactions in the specified transaction group.

Transaction group

Deliver Transaction Group

Fetch a list of transactions, sorted by the date they were created from newest to oldest.
Generally this endpoint is used to display a list of transactions in a UI.
If you are looking to regularly fetch and check for new transactions for programmatic usage, you should use the `ListPollingTransactions` operation instead.

List transactions

List Transactions

This endpoint is used to regularly poll for new transactions that have been processed in Core.

You must define one of `startDateTime` or `pageToken` when making a request.

You may optionally define a `pageSize`. The minimum `pageSize` is 1, and the maximum `pageSize` is 1000. The default is 100.

`startDateTime` takes a string in ISO 8601 format. (ex: `2023-08-10T18:00:00Z`). 
`startDateTime` must be set to at least 1 minute in the past.

The results will contain transactions that occurred after this `startDateTime`. Starting from the oldest to newest transactions ordered by the `processedAt` field. Note, this is _exclusive_ of the `startDateTime`, a transaction occuring at exactly `2023-08-10T18:00:00Z` for instance, would not be included. In addition, there is a 15 second window where newly created transactions will not be included to account for any network latency or clock drifts within the systems to ensure you do not miss any transactions.

Each request will _always_ return a `nextPageToken`, regardless of whether there are new transactions or not.

We DO NOT recommend trying to roll your own polling strategy leveraging `startDateTime` only. There are edge cases around two transactions occuring at the _exact_ same time and being on the edge of a pagination which could cause you to miss one due to the exclusive nature of `startDateTime`. We recommend using `pageToken`'s instead.

When making subsequent polling requests (not initiating with `startDateTime`), the `pageToken` can be used to continue iterating through pages of transactions. Usage of the `pageToken` guaruntees you will not miss any transactions on the stream. If at any point there are no more new transactions in the `item` array, you will still receive a `nextPageToken`. Continue to use this token to poll for new transactions. Once there are new transactions, they will be returned in the `item` array.

`pageToken`'s you have retrieved can serve as checkpoints. They do not expire, and you can always start from that point in the transaction stream again if you need to catch a system up or recover from a failure. Storing `pageToken`'s as part of your polling process is encouraged.

`pageToken`'s are unique per request, opaque, and should not be parsed or modified in any way. They are not guaranteed to be in any particular format, and may change in the future.


Poll transactions

Transaction

Get Transaction

This endpoint retrieves a transaction's input document before it passes through any translation and mappings.

Input

Get Transaction Input

Healthcare

EDI platform

List Enrollments

Authorizations

Query Parameters

Response