canonical: https://jentic.com/apis/stedi.com

# Stedi APIs

Stedi is a healthcare EDI and clearinghouse platform whose APIs handle eligibility checks, claim status inquiries, claim and attachment submission in JSON or raw X12, provider enrollment tracking, a searchable payer directory, and the underlying event and execution engine that runs these transactions. The six APIs in this portfolio cover the full path from checking a patient's coverage through submitting claims and monitoring the executions that process them.

## For AI agents

An agent can run patient eligibility checks, submit professional and institutional claims and their attachments in JSON or raw X12, poll claim status, batch eligibility runs, look up healthcare payers, track provider enrollments, and inspect the events and executions that process these transactions. It moves across Stedi's healthcare, enrollment, payer, and core execution APIs with one set of credentials.

## Scope

Use for: Healthcare EDI transactions: eligibility checks, claim and attachment submission in JSON or raw X12, claim status, provider enrollment, payer directory lookup, and inspecting the executions that process them.

Not supported:
- clinical records
- patient scheduling
- general payment processing
- communications
- crm

## APIs

| API | Category | Endpoints | Description |
| --- | --- | --- | --- |
| Core | developer-tools | 30 | Programmatically retryevent, listexecutions. |
| Stedi Healthcare | healthcare | 22 | Programmatically claimstatus, claimstatusrawx12. |
| Stedi Enrollment | payments | 15 | Programmatically deleteenrollmentdocument, createenrollmentdocumentdownload. |
| Stedi Manager | developer-tools | 5 | Programmatically batcheligibilitychecks, getbatch. |
| Stedi Payers | payments | 4 | Programmatically getpayerrecord, listpayerrecords. |
| Stedi Healthcare Claims | healthcare | 2 | Programmatically createclaimattachmentfile, submitclaimattachmentrawx12. |

## Which API to use

| Need | API | Why |
| --- | --- | --- |
| Check patient eligibility or submit and status a claim | stedi-healthcare-api | Runs real-time eligibility checks, claim status inquiries, and professional and institutional claim submissions in JSON or raw X12. |
| Attach a document to a healthcare claim | stedi-healthcare-claims-api | Handles claim attachment files and raw X12 attachment submissions, which the main healthcare API does not cover. |
| Run eligibility for many members at once | stedi-manager-api | Starts batch eligibility runs, polls them to completion, and returns batch items and per-check PDFs. |
| Look up which payer to route a transaction to | stedi-payers-api | Searches and lists the payer directory and returns individual payer records by Stedi id. |
| Track a provider's enrollment with a payer | stedi-enrollment-api | Creates, updates, lists, and exports provider enrollments and their supporting documents. |
| Inspect or retry the processing behind a transaction | stedi-core-api | Lists executions, reads their faults and input, and retries failed events and executions. |

## Cross-API use cases

### Verify coverage then submit the claim

An agent runs a real-time eligibility check for a patient, confirms active coverage, then submits the professional or institutional claim to the same payer, using the payer directory to resolve the correct destination.

Example prompt: Search the payer directory for the payer, run an eligibility check, then submit the claim if coverage is active

### Submit a claim with a supporting attachment

An agent submits a claim through the healthcare API and adds the required supporting document as a claim attachment file or raw X12 attachment submission in the same run.

Example prompt: Submit the claim, then create the claim attachment file and submit it against that claim

### Batch eligibility then trace failures

An agent starts a batch eligibility run, polls it to completion, and for any failed items reads the execution faults and input from the core engine to diagnose and retry the transaction.

Example prompt: Start a batch eligibility run, poll for results, then read execution faults and retry any failed executions

### Enroll a provider then run its transactions

An agent confirms a provider's enrollment with a payer, resolving the payer from the directory, before running eligibility or claim transactions that depend on that enrollment being active.

Example prompt: Resolve the payer, list the provider's enrollments, and confirm active status before transacting

## Why Jentic

- **Setup:** Wiring the six Stedi APIs by hand means configuring the Authorization header key against separate dated US regional hosts for healthcare, claims, enrollment, payers, and the core engine, and threading ids between them yourself. Through Jentic you install once, add the Stedi APIs you need from the Jentic API Directory, store the one API key, and your agent calls them.
- **Permission scoping:** Your own rules decide which Stedi operations an agent may call, so a read-only agent can look up payers, check eligibility, and read enrollments while claim submission, enrollment deletion, and execution retries stay out of reach unless you add them. Where an API puts a resource id in the path, such as an enrollment or execution id, a rule can pin the agent to a single record.
- **Credential handling:** Your Stedi API key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context, which matters for the protected health information these APIs carry.
- **Discovery method:** Agents search the Jentic directory by intent such as 'check patient eligibility', 'submit a healthcare claim', or 'look up a payer', and Jentic returns the matching Stedi operation with its input schema so the agent calls the right endpoint across the portfolio without browsing the reference docs.

## Related vendors

- **athenahealth** — Healthcare platform with eligibility and claims capabilities, an alternative for revenue-cycle transactions.
- **Oystehr** — Healthcare developer platform offering an alternative approach to EHR and claims operations.
- **Change Healthcare** — Established clearinghouse for eligibility, claim status, and claim submission across payers.
- **Availity** — Payer connectivity network for eligibility, claims, and enrollment transactions.

## FAQ

### What can an agent do across the Stedi APIs?

An agent can check patient eligibility, submit professional and institutional claims and their attachments in JSON or raw X12, poll claim status, run batch eligibility jobs, look up payers in the directory, track provider enrollments, and inspect or retry the executions that process these transactions. These span the healthcare, enrollment, payer, and core execution APIs.

### Do the Stedi APIs share one set of credentials?

Yes. All six APIs use the same apiKey model, with a Stedi API key passed in the Authorization header, so a single credential covers eligibility, claims, enrollment, payer lookup, and the core execution engine.

### Which Stedi API should I use for a given task?

Use the Stedi Healthcare API for eligibility, claim status, and claim submission; the Stedi Healthcare Claims API for claim attachments; the Stedi Manager API for batch eligibility; the Stedi Payers API for the payer directory; the Stedi Enrollment API for provider enrollments; and the Stedi Core API to inspect and retry the executions behind them.

### Do the Stedi APIs support raw X12 as well as JSON?

Yes. The healthcare and claims APIs accept both JSON and raw X12 for eligibility checks, claim submissions, and claim attachments, so an agent can work in whichever format the downstream payer or workflow requires.

### Can I compose a workflow across several Stedi APIs?

Yes. A common pattern is to resolve a payer from the directory, check eligibility, submit a claim with an attachment, and then trace any failed processing through the core execution engine. Because the APIs share one account, an agent can chain these steps without switching credentials.

### Is Stedi a full clinical or scheduling system?

No. Stedi covers healthcare EDI and transaction processing: eligibility, claims, enrollment, payer data, and the execution engine. It does not manage clinical records, patient scheduling, or general payment processing outside the healthcare transaction flow.