Contact us

Changelog

Stedi

Healthcare

EDI platform

API Reference

Get started

Log in

Support

Automate transactions with the only API-first clearinghouse

Stedi Healthcare

Supported payers

Overview

Eligibility checks

Monthly refresh checks

Troubleshooting

Eligibility troubleshooting

Payer benefit response

Eligibility Manager

Submit claims

Code lists

Claims code lists

Enhanced validation

Enhanced claim validation

Check claim status

Retrieve payer responses

Retrieve and correlate claim responses

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

Data and privacy

HIPAA compliance

HIPAA compliance on Stedi

List Payers

Eligibility Check

Eligibility Check Raw X12

Testing: Send mock requests

Send mock requests to the Eligibility Check endpoint

Professional Claims

Professional Claims Raw X12

Institutional Claims

Claim Status

Claim Status Raw X12

CMS-1500 PDF

CMS-1500 Claim Form PDF

277CA Report

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.

Transaction

Create Outbound Transaction

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

Transaction Group

Deliver Transaction Group

This endpoint generates and delivers fully-formed EDI files to your trading partners.

Interchange

Create Outbound Interchange

This endpoint stages a transaction for outbound delivery.

Stage transactions

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

Get Transaction

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

Input

Get Transaction Input

This endpoint retrieves a transaction's output document after it has been translated.

Output

Get Transaction Output

Fetch a list of executions, sorted by the date they were created from newest to oldest.

List executions

List Executions

This endpoint is used to regularly poll for new executions that have been processed by Stedi.

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 executions that occurred after this `startDateTime`. Starting from the oldest to newest executions ordered by the `processedAt` field. Note, this is _exclusive_ of the `startDateTime`, a execution 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 executions will not be included to account for any network latency or clock drifts within the systems to ensure you do not miss any executions.

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

We DO NOT recommend trying to roll your own polling strategy leveraging `startDateTime` only. There are edge cases around two executions 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 executions. Usage of the `pageToken` guaruntees you will not miss any executions on the stream. If at any point there are no more new executions in the `item` array, you will still receive a `nextPageToken`. Continue to use this token to poll for new executions. Once there are new executions, 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 execution 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 executions

Poll Executions

Fetch a list of transactions for a given file execution, sorted by the date they were created from newest to oldest. Includes the full transaction details.

List execution transactions

Get Execution Transactions

Retrieve the file execution details for a given executionId.

Execution

Get Execution

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

Get Execution Input

This endpoint retrieves an execution's metadata document.

Metadata

Get Execution Metadata

This endpoint retrieves an execution's output document.

Get Execution Output

This endpoint stages a fragment for outbound delivery.

Stage fragment

This endpoint fetches a fragment by its index for a given transaction.

Fragment

Get Fragment

This endpoint retrieves a transaction fragment's output document after it has been translated.

Get Fragment Output

Maps the provided JSON to a different shape according to the specified mapping definition.

Eligibility checks

Claims processing

Administrative

Support

Contact us

Eligibility checks

Claims processing

Administrative

​Contact us

Contact us