Changelog

Stedi

Healthcare

EDI platform

API Reference

Get started

Log in

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

Invoke mapping

Invoke Mapping

A code that specifies what went wrong.

Value     | Description
----------|------------
mapping_failed | The input JSON could not be mapped using the specified mapping definition.
validation_failed | The input JSON or the output JSON does not conform to the specified JSON Schema.

Validation errors separated by the origin of the validation error: source or target. Only present in the response if validation_mode=strict was used.

JSON Schema keyword which is the reason of a particular validation failure, e.g.: required, pattern, maxItems, etc.

Path to the property of the JSON document in JSON Pointer format that caused the validation failure.

Path to the keyword within JSON Schema in JSON Pointer format that caused the validation failure.

Error message that describes the reason of a particular validation failure.

Mapping input document validation errors together with the input document that caused these errors.

The body of the request should be the JSON you want to map. It can take any shape as long as it is valid JSON.

Mapping output document validation errors together with the output document that caused these errors.

The body of the response is the mapped JSON. It doesn't contain any extra fields and it's isn't wrapped in any way.

httpApiKeyAuth

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

The server response for authorization failure.

The server response when the specified resource cannot be found after an API request passes authentication and authorization.

The server response for the request too large error.

The server response when usage plan or account-level throttling limits exceeded.

Automate transactions with the only API-first clearinghouse

Stedi Healthcare

Supported payers

Enrollments

Overview

Real-time eligibility checks

Eligibility checks

Batch refresh checks

Troubleshooting

Eligibility troubleshooting

Interpret benefit response

Code lists

Eligibility code lists

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

Data and privacy

HIPAA compliance

HIPAA compliance on Stedi

Support

List Payers

Create Provider

Create Enrollment

Provider

Enrollment

List Providers

List Enrollments

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

CMS-1500 PDF

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

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

Healthcare

EDI platform

Invoke Mapping

Authorizations

Path Parameters

Query Parameters

Body

Response