Changelog

Test ERAs now support denials and partial payments

Stedi's test claims workflow now returns denied and partially paid test Electronic Remittance Advice (ERAs).

The test claims workflow lets you submit a test claim to the Stedi Test Payer and get a test ERA. You can choose the payment outcome with a prefix on the subscriber's member ID.

Previously, every test ERA showed every service line as paid in full. Now, the same test claims can return a denied or partially paid test ERA. You can validate how your system posts denials, contractual adjustments, and patient responsibility before you send production claims.

Submitting the test claim

To choose a payment outcome, add STEDI_PAID_, STEDI_PARTIALLY_PAID_, or STEDI_DENIED_ to the front of the subscriber's member ID. The prefix works for professional, dental, and institutional claims. It applies to every service line on every claim for that subscriber.

For example, in a Professional Claim (CMS-1500) JSON API request:

{
  "insured": {
    "memberId": "STEDI_DENIED_0000000001", // Returns a denied test ERA.
    ...
  },
  ...
}

Receiving the test ERA

The prefix determines what the test ERA reports for each service line, using fixed amounts. A missing or unrecognized prefix returns a fully paid test ERA.

Test ERAs only support primary claims. Paid and partially paid test ERAs report the claim status as processed as primary, with payment method ACH. Denied test ERAs report the claim status as denied, with payment method NON (no payment).

Test ERAs can't simulate every production outcome, such as split or bundled claims.

Requirements

You need an ERA enrollment with the Stedi Test Payer. If Stedi's claim edits reject the claim, you don't get a test ERA.

For more information, see our test ERA scenarios docs.

Claim edit: Paper claims missing referenced attachments

Stedi now rejects 837P professional, 837D dental, and 837I institutional paper claims that reference an electronic attachment you didn't send in the same submission.

Paper claims and attachments

With paper claims, Stedi prints the claim and mails it to the payer. If the claim references a 275 claim attachment, Stedi prints the attachment and mails it in the same package.

A claim references an electronic attachment with an attachment control number and a transmission code of EL (Electronically Only). For SFTP submissions, the matching 275 must be in the same interchange (ISA/IEA envelope) as the claim.

How the edit works

The edit only runs on paper claims – claims with the receiver ID set to PAPER. If you submit a paper claim that references an attachment you didn't include in the same submission, the payer gets the claim without its supporting documents and may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

Stedi runs this edit when it prepares the claim for printing, after it accepts the submission. So the Claim Submission API endpoints don't return an error in real time for this edit.

If you submit a claim using the API or SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A6>21*[DATE]*U*[AMOUNT]******A6>294*A6>489*Missing Attachment. This claim requires the referenced attachment to be submitted as part of the same submission. Correct and resubmit.~

To fix the claim, resubmit it together with the attachment it references.

Related claim edits

Stedi has another edit for claims that indicate an attachment but don't include an attachment control number. See Claim edit: Missing attachment control number.

Claim edit: Reserved X12 delimiter in a field value

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims with a field value that contains a character reserved as an X12 delimiter.

How the edit works

X12 standards require that a small set of characters be used only to mark the boundaries between segments, elements, and components. Stedi rejects a claim when one of them appears inside a field value: asterisk (*), greater-than sign (>), caret (^), grave accent (`), or tilde (~).

The edit checks every text field in the claim. Characters that aren't delimiters pass – the apostrophe in O'BRIEN and the hyphen in SMITH-JONES CLINIC are both valid. So is the colon, which an 837 doesn't use as a delimiter.

A reserved character inside a value collides with those boundaries, so the claim can't be read as valid X12. If a field value contains one, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid character. The Subscriber First Name (2010BA/NM1-04) contains a reserved X12 delimiter character (greater-than sign). Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, entity identifier code, and error message:

STC*A7>481>HK*[DATE]*U*[AMOUNT]********Invalid character. The Subscriber First Name (2010BA/NM1-04) contains a reserved X12 delimiter character (greater-than sign). Correct and resubmit.~

The error names the field and the character, but never repeats the value you submitted – that would put the delimiter back into the acknowledgment.

If more than one field in a claim contains a reserved character, you get one rejection per field.

Related claim edits

Stedi has another edit for field values that run longer than the maximum length allowed by X12 standards. See Claim edit: Field values longer than maximum length.

Event destinations now support file processing events

You can now subscribe to file processing events using event destinations:

• file.processed – Stedi generates this event when it successfully processes a file, such as a 277CA claim acknowledgment from a payer.

• file.failed – Stedi generates this event when it fails to process a file, such as an SFTP claim submission it can't parse.

• transaction.processed – Stedi generates this event when it translates a transaction, such as a payer's Electronic Remittance Advice (ERA) into JSON.

You can subscribe on the Stedi portal's Event Destinations page, with the Event Destination APIs, or with the Stedi SDKs.

An installed OAuth app can also subscribe to these events in its provider's account.

Event payloads

Stedi events use a thin event schema. A thin event notifies you that a resource changed, but it doesn't include the resource's data.

A single file with multiple transactions produces one file.processed event and one transaction.processed event per transaction. The relatedResources array identifies the transaction type.

{
  ...
  "resource": {
    "id": "019bb508-dc63-73a1-8ddc-9d4720299072",
    "type": "transaction"
  },
  "relatedResources": [
    {
      "id": "019bb508-dc63-73a1-8ddc-9d4720299072",
      "type": "transaction.x12.835" // ERA
    }
  ],
  "type": "transaction.processed"
}

Once you receive an event, retrieve the details using Stedi's APIs or the Stedi portal:

• transaction.processed – Pass the transaction ID in relatedResources to the Get 835 ERA Report or Get 277CA Report endpoint.

• file.processed and file.failed – Pass the execution ID in resource.id to the Retrieve File Execution Input endpoint.

For event schemas, see our event types reference.

Introducing Agentic Discovery

You can now find a patient's insurance coverage and benefits in one click using Agentic Discovery.

Agentic Discovery combines eligibility checks, automated check recovery, and insurance discovery into a single, automated workflow.

With Agentic Discovery, you start by entering the data you have about a patient, such as name, date of birth, and – if you know it – the payer ID. The agent runs an eligibility check. If the check succeeds, the agent stops. If the check fails, the agent tries to recover it using Stedi's best practices. For example, the agent may try follow-up eligibility checks with variations of the patient's name.

If recovery fails, the agent then runs an insurance discovery check. Insurance discovery checks can find coverage based on limited information, even if the original eligibility check had missing or incorrect information.

Previously, you had to manually sequence and run each of these steps separately.

Agentic Discovery is now the default way to run eligibility checks in the Stedi portal. It also replaces the previous iteration of eligibility check recovery in the Stedi Agent. The Resolve with Stedi Agent option is still there, but it now runs the more complete Agentic Discovery check instead.

Watch the 2026 Stedi Keynote announcement:

How to run an Agentic Discovery check

You can start an Agentic Discovery check from the Stedi portal in three ways:

• Click + New eligibility check in the checks view, fill out the form, then under Run as, click Agentic Discovery.
• Select Agentic Discovery on the Stedi Agent's Chats page.
• Click Launch Agentic Discovery for failed eligibility checks in the checks view.

The last two options open a form in the Stedi Agent. To run an Agentic Discovery check, enter or change the patient, provider, and payer details, then click Submit.

To run a standard eligibility check without Agentic Discovery, click + New eligibility check, fill out the form, then under Run as, click Single eligibility check.

What data do I need to run an Agentic Discovery check?

You only need to provide:

• The patient's first name
• The patient's last name
• The patient's date of birth, member ID, or Social Security Number (SSN)
• The provider's NPI

We recommend you include as much information as you have, such as the state of the patient's address. Additional information increases the chances of finding active coverage.

If you don't provide a date of service, the check defaults to today's date. If you don't provide a Service Type Code (STC), the check defaults to 30 (Health Benefit Plan Coverage).

If you don't provide a payer, the agent runs an insurance discovery check using the patient's information.

Transaction enrollment with the Stedi insurance discovery payer (payer ID: DISCOVERY) isn't required, but we strongly recommend it. Enrollment lets Stedi run Medicare Beneficiary Identifier (MBI) lookups as part of insurance discovery checks, which can improve results.

Availability and pricing

Agentic Discovery is available for all Stedi production accounts.

Agentic Discovery checks are priced per agent run. You won't be billed separately for underlying eligibility or insurance discovery checks the agent uses. For pricing, see our Pricing page.

Agentic Discovery isn't available in test mode or sandbox accounts. In test mode, use the standard eligibility check form to run mock eligibility checks.

For more details, see our announcement blog.

Introducing claim lifecycle tracking in the Stedi portal

You can now track a claim's full lifecycle – from submission to payer adjudication – in the Stedi portal's claims view. For example, you can see whether the payer denied a claim, or how much the payer paid.

Previously, information in the claims view was derived solely from claim submissions and related 277CA claim acknowledgments. To get payment information for a claim, you had to jump from the claim's timeline to Electronic Remittance Advice (ERAs) with a matching patient control number (PCN).

Now, the portal displays information from those ERAs directly in the claims view, including:

• Claim processing status – Whether the claim was processed, denied, rejected, or is still being processed.
• Amount paid – What the payer paid on the claim, next to the amount charged.
• Patient responsibility – The share the patient owes.
• Adjustments – Claim-level and service line adjustments.
• Denial reasons – Why the payer denied the claim.
• Reversals – Whether the payer reversed a previous payment.

Watch the 2026 Stedi Keynote announcement:

Claim filters

The claims list view has two new filters:

• Reversals – Claims with payment reversals, or claims without them.
• Amount paid – Claims with a minimum or maximum paid amount.

For example, you can set the new Amount paid filter's Min and Max values to 0 to see unpaid claims.

We've also renamed the existing Total charges column and filter to Amount charged. Other columns and filters remain unchanged.

New claim processing statuses

We've added three claim processing statuses that are derived from the claim's matched ERAs:

• Processed by payer – The payer completed adjudication and accepted responsibility for the claim. This doesn't mean the payer paid the claim in full, or paid it at all.
• Denied – The payer completed adjudication and denied responsibility for the claim.
• Unknown – Stedi can't determine a single status for the claim. This usually happens when the payer's responses are mixed or incomplete.

The Unknown status replaces the old Invalid status, which only applied to 277CA claim acknowledgments with unrecognized status codes.

The Submitted, Received, Rejected, and Accepted statuses remain unchanged. For more, see How we determine status in our docs.

Claim timeline

Each claim's timeline now includes a card for every claim payment information record from an ERA. Each card shows the claim processing status, the amount charged, the patient responsibility, the amount paid, and the ERA trace number.

Resubmissions carry their own payment records, so you see the payments tied to each attempt.

Claim payment information details

Hover over a claim payment information card and click See more detail to open its details. That view shows payment information for one claim:

• The linked claim, with a link back to its timeline.
• Claim-level payment information: total charged, total paid, patient responsibility, and adjustments. If the claim was denied, denial reasons are also included.
• Service line details, with line-level payment amounts and adjustments.

You can view the CLP (Claim Payment Information) segment of Loop 2100 for the related ERA in the X12 tab. You can also download a PDF for a single claim payment information record.

ERA detail view

Each ERA detail view has a claim payment information table with one row per claim payment information record. Click a row to open the details for that claim.

If you receive ERAs through Stedi but submit claims elsewhere, you still get the claim payment information details for each record in an ERA.

Availability and pricing

Claim lifecycle tracking is available now in the Stedi portal's claims view for all Stedi production accounts at no extra cost.

For more details, see our announcement blog.

Introducing OAuth Stedi apps

Stedi apps are pre-configured integrations between a provider's Stedi account and an external platform, like an electronic health record (EHR), practice management system, or revenue cycle management (RCM) system.

We're releasing a completely revamped, OAuth-based version of Stedi apps that allows deeper, more seamless integration with external applications. OAuth Stedi apps include several new features:

• One-click installation – Providers can install a Stedi app without copying API keys or SFTP credentials between Stedi and the app.

• Support sessions – App developers can open a time-limited support session in a provider's Stedi account.

• Self-provisioning – An installed Stedi app can create its own event destinations and SFTP users, run eligibility checks, and manage transaction enrollments in a provider's Stedi account.

• Self-service app registration – App developers can create an app and get OAuth credentials directly in the Stedi portal.

• Redesigned Stedi app store – App developers can list their app so providers can find and install it.

Previously, providers had to generate API keys and SFTP credentials and share them with the app developer. To provide support, the app developer's staff had to join the provider's Stedi account as members. That access lasted until the provider removed the members.

Now, industry-standard OAuth replaces that credential handoff. A provider installs an app by approving one consent screen. The app developer's support staff can work in a provider's Stedi account through a time-limited session instead of a standing login.

Important: We're not changing existing Stedi apps that use API keys or SFTP credentials as part of this release. All existing Stedi apps will continue working. If you're a current Stedi app developer who wants to upgrade to OAuth, contact us.

Watch the 2026 Stedi Keynote announcement:

One-click installation for providers

A provider can click an install link in the app developer's platform, or select the Stedi app in the redesigned Stedi app store. Stedi then shows a consent screen with the app's name and the exact permissions the app requests.

The provider approves, and the connection is live.

Support sessions

App installation grants the app developer the ability to run a time-limited support session in the provider's account. When a provider uninstalls the app, that ability is removed. Support sessions use the app's permissions – nothing more.

Self-provisioning

Once the provider approves the app, the app can set up the account itself. It calls Stedi APIs with its own tokens.

An app can create event destinations, create SFTP users, run eligibility checks, and manage transaction enrollments. It acts under the exact permissions the provider approved on the consent screen. Stedi labels each resource the app creates, so providers can see what the app manages.

Stedi also sends app.installed and app.uninstalled events to the app developer's own Stedi account. Providers can uninstall an app at any time, and its access ends within an hour.

Self-service for app developers

App developers can now register apps in the Stedi portal and get their OAuth credentials there. The entire process is self-service.

App developers can list their app in the redesigned Stedi app store so providers can find it. Each Stedi account can have one active app installed.

Pricing and availability

It's free to build and publish a Stedi app. There are no developer fees. It's also free for providers to install an app.

OAuth Stedi apps are in private preview. We're onboarding new Stedi app developers. Contact us if you want to build a Stedi app.

For more details, see our announcement blog.

Introducing our redesigned JSON Real-Time Eligibility Check API

We're releasing a redesigned version of our JSON Real-Time Eligibility Check API endpoint: POST https://healthcare.us.stedi.com/2026-06-01/eligibility-check.

The new endpoint's response format makes it easier to parse a patient's benefits.

The legacy JSON Real-Time Eligibility Check API endpoint returns responses in a structure that mirrors the X12 eligibility response. Benefits for different plans and different benefit types are intermixed in a flat benefitsInformation array. The array is "polymorphic": the fields in each entry change depending on the benefit type. The responses also use X12 codes, like C for a deductible or F for limitations, so you map each one to its meaning.

The new endpoint removes the polymorphism. It groups benefits by health plan. In each plan, it breaks the payer's benefit details out into separate typed objects: statuses (for example: ACTIVE_COVERAGE and INACTIVE), coPayment, coInsurance, deductible, and more. It spells values out: ACTIVE_COVERAGE instead of 1, IN_NETWORK instead of Y. Each benefit names the Service Type Code (STC) or procedure code it applies to.

{
  "payerId": "87726",
  "plans": [
    {
      "name": "Gold Plan HMO",
      "benefits": {
        "statuses": [
          {
            "status": "ACTIVE_COVERAGE",
            "coverageLevel": "INDIVIDUAL",
            "network": { "indicator": "IN_AND_OUT_OF_NETWORK" },
            "service": {
              "system": "STC",
              "value": "30",
              "definition": "Health Benefit Plan Coverage"
            }
          }
        ],
        "coPayment": [
          {
            "amount": "15",
            "coverageLevel": "INDIVIDUAL",
            "messages": ["SPECIALIST"],
            "network": { "indicator": "IN_NETWORK" },
            "service": {
              "system": "STC",
              "value": "96",
              "definition": "Professional (Physician)"
            },
            "timePeriod": "VISIT"
          }
        ]
      }
    }
  ],
  ...
}

To run checks with the new endpoint, you only need to provide the same information you use to run eligibility checks today: the payer ID, the provider's name and NPI, the patient's details, and the STC or procedure code you want benefits for.

Watch the 2026 Stedi Keynote announcement:

Test mode support

You can use the new endpoint to run pre-defined mock eligibility checks in test mode with a test API key. Mock eligibility checks are available on all Stedi accounts, including free sandbox accounts.

Existing integrations

We're not deprecating the legacy JSON Real-Time Eligibility Check API endpoint or any other functionality as part of this release.

This release doesn't introduce any breaking changes. Your existing integrations will continue working as they do today.

Availability and pricing

The new endpoint is available on all Stedi accounts.

Mock eligibility checks are free. Production eligibility checks are priced per transaction. Checks with the new endpoint cost the same as checks with the legacy endpoint. For pricing, see our Pricing page.

For more details, see our announcement blog.

Introducing Stedi Lockbox

Providers can now receive payer paper checks, paper remits, and other mail items at a lockbox address managed by Stedi. A lockbox is a secure mailing address that receives mail on the provider's behalf. The provider can give the address to payers that require a mailing address for physical mail. Stedi deposits any checks received into a Stedi Treasury account automatically. Stedi scans the remits and other mail into PDFs you can view and download.

Checks become payment records in the Stedi portal. Paper remits and other mail become PDFs with OCR text that can be used for downstream processing.

Watch the 2026 Stedi Keynote announcement:

Automatic check deposits

Electronic Funds Transfers (EFTs) are the standard option for payer payments, but payers don't always pay electronically. Many still mail paper checks, and many mail paper remits – explanations of payment (EOPs) or explanations of benefits (EOBs) – instead of Electronic Remittance Advice (ERAs).

All that paper turns into manual work for the provider. Someone has to open the envelopes, match each check to its remit, and deposit the checks by hand.

Stedi Lockbox takes that work off the provider. Stedi receives the mail, scans it, and deposits any check into the associated Stedi Treasury account.

These check deposits appear in the Stedi portal the same way EFTs do, with one addition – a Mail card showing that the payment arrived as a paper check.

The related payment's detail page includes a scanned image of the check.

Paper remits and other mail

When a lockbox receives a paper remit, such as an EOP or EOB, Stedi makes it available in the related Stedi account as a PDF. Each PDF includes optical character recognition (OCR) text, so you can process the contents downstream.

The same applies to every other item of mail. You get the PDF, the OCR text, and the sender, then decide what to do next.

Availability and pricing

Stedi Lockbox is in private preview for Stedi production accounts. Reach out if you're interested in joining the preview.

For more details, see our announcement blog.

Introducing Stedi Treasury

You can now enroll for EFTs, then receive and automatically reconcile payments from payers with Stedi Treasury.

Stedi Treasury unlocks simple EFT enrollment along with automatic reconciliation. You can enroll for EFTs and track the entire claim lifecycle from claim submission to payout in the Stedi portal.

Previously, providers had to navigate a confusing variety of payer-specific processes to enroll for EFTs. Reconciling each payment to the corresponding ERA and related claims took a series of manual steps.

Watch the 2026 Stedi Keynote announcement:

How Stedi Treasury works

When a provider signs up for Stedi Treasury, we provision a demand deposit (DDA) bank account in the provider's name via our banking partner, Grasshopper Bank. Treasury accounts are in the provider's name, FDIC-insured up to $250,000, and are fully integrated with your Stedi account for payment tracking and reconciliation. Each Treasury account takes about five minutes to set up.

With Treasury, you submit and track EFT enrollments with the same transaction enrollment process you already use for ERAs, either using the Stedi portal, CSV, or API. Where possible, Stedi handles the paperwork for you, including generating voided checks and verification letters, and verifying micro-deposits.

Once the enrollment process is complete, payments from payers land in the provider's Stedi Treasury account. Stedi then automatically pays out the full amount to the provider's external bank account as a next-day ACH payment. Stedi doesn't delay or batch the funds.

Setup for Stedi Treasury takes three steps:

1. Create one or more billing entities for the provider.
2. Link each billing entity to an external bank account.
3. Enroll the provider for EFTs through Stedi with each payer.

Stedi supports over 750 payers for EFT enrollment, with more being added every day. Check the Payers API or the Stedi Payer Network to confirm that a payer supports EFT and to check their enrollment requirements.

Payments and payouts

The Payments page lists funds a payer sends to a Treasury account. A payment is Pending while the funds settle, then Received.

The Payouts page lists payouts – ACH deposits from a Stedi Treasury account to the linked external bank account. Each payout lists its current status, moving from Pending to In transit to Paid.

Each payment gets its own payout for easier tracking. If a Stedi Treasury account receives a $100 payment, Stedi issues a $100 payout. Payouts aren't bundled. Any fees are billed separately.

You can also access monthly bank statements showing all credits and debits to the billing entity's Stedi Treasury account.

Automatic reconciliation

If you submit claims and receive ERAs through Stedi, you can trace an individual payment on the payment's detail page back to its ERA and claim in the Stedi portal's claims view.

Stedi associates payments with ERAs based on the reassociation trace number returned in both.

Stedi Lockbox

A Stedi Lockbox is a mailing address that receives payer mail on the provider's behalf. When you sign up for Stedi Lockbox, you get one. You can give the address to payers whenever they require a mailbox for paper remits.

When a Stedi Lockbox receives a paper check, it's automatically scanned and deposited into the associated Stedi Treasury account. These check deposits appear in the Stedi portal the same way EFTs do, with one addition – a Mail card showing that the payment arrived as a paper check.

When a Stedi Lockbox receives a paper remit, such as an EOP or EOB, Stedi makes it available in the related Stedi account as a PDF. Each PDF includes optical character recognition (OCR) text, so you can process the contents downstream.

Availability and pricing

Stedi Treasury is generally available in the Stedi portal for Stedi production accounts. API access is coming soon. Contact us for pricing and to turn it on for your account.

Stedi Lockbox is in private preview for Stedi production accounts. Reach out if you're interested in joining the preview.

For more details, see our announcement blog.

–

Stedi is a financial technology company, not a bank. Banking services are provided by Grasshopper Bank, N.A., Member FDIC. The FDIC's deposit insurance coverage only protects against the failure of an FDIC-insured bank.

Introducing test mode for claims

You can now test the entire claims workflow using test mode, including Stedi test API keys and test SFTP credentials. You can simulate a claim's lifecycle from end to end without submitting a real claim to a payer.

Previously, you could only submit test claims in production and had to mark each claim as a test. You couldn't include claim attachments for test claims.

Now, you can use test mode to:

• Submit test claims and validate them using Stedi's database of claim edits.
• Include claim attachments for test claims.
• Get 277CA claim acknowledgments for test claims.
• Get test Electronic Remittance Advice (ERAs) for claims submitted to the Stedi Test Payer.
• Get 999 Implementation Acknowledgments for rejected test claims that you submitted through SFTP.

Test mode works for all three 837 claim types: 837P professional, 837D dental, and 837I institutional.

Watch the 2026 Stedi Keynote announcement:

Deprecating test claims in production

We're deprecating the ability to submit test claims in production. New Stedi accounts can only submit test claims using a Stedi test API key, test SFTP credentials, or test mode in the Stedi portal.

If you already submit test claims in production, your current workflows will continue working. We recommend switching to test mode for test claim submissions. This ensures a mistyped usageIndicator or ISA15 can't send a live claim to a real payer.

For more information on submitting test claims, see Test claim workflows in our docs.

Claim acknowledgments and ERAs for test claims

The payer you send a test claim to determines which test responses, such as 277CA claim acknowledgments or test ERAs, you get back. It also determines which claim edits Stedi uses to validate the claim.

Availability and pricing

Test mode for claims is available for free on all Stedi production accounts.

You can't submit test claims using a Stedi sandbox account. To submit test claims, upgrade to a production account.

For more details, see our announcement blog.

Introducing the Claims Lifecycle API, Stedi's headless RCM engine

You can now use Stedi's Claims Lifecycle API endpoints to retrieve the same claim records that power the claims view in the Stedi portal. The endpoints return the claim's status, submission date, charge amounts, paid amounts, and full history, providing a powerful headless RCM engine that can drive external applications.

Previously, the Stedi portal's claims view was the only place to see a claim's full lifecycle. Through the API, you received each response on its own – a 277CA claim acknowledgment here, an ERA there. You had to match each response back to the original claim, usually on the patient control number (PCN).

Now Stedi does the matching and returns the result. The new endpoints serve the same claim data that powers the claims view, so your dashboard can show what the portal shows.

Watch the 2026 Stedi Keynote announcement:

Claim records

A claim record holds summary information about a claim, including its current status. A Retrieve Claim API response contains a single claim record:

{
  "id": "clm_01K6XFP3TZ8RA9X84963NMW40N",  // Stedi's claim ID
  "patientControlNumber": "123456",
  "patientName": { "firstName": "John", "lastName": "Doe" },
  "type": "PROFESSIONAL",
  "stediPayerId": "ABCDE",
  "datesOfService": { "start": "2026-01-05" },
  "submittedAt": "2026-01-16T10:00:00Z",  // Time Stedi processed the most recent submission
  "status": "PROCESSED",
  "statusReportedBy": "PAYER", // PAYER or CLEARINGHOUSE
  "totalClaimChargeAmount": "832.00",
  "totalClaimPaidAmount": "200.00" // Sum of payments matched to the claim from ERAs. Includes reversals (negative amounts)
}

The claim record's status field uses the same claim processing statuses as the portal: SUBMITTED, RECEIVED, ACCEPTED, REJECTED, PROCESSED, DENIED, and UNKNOWN.

Claim IDs

Each claim record includes a claim ID. The ID stays the same for the life of the claim. A resubmission updates the record, but doesn't change the claim ID. One claim ID tracks the claim across every submission.

Filters and pagination

You can use the List Claims API endpoint to filter a list of claim records by status, patientControlNumbers (up to 20), and a submittedAfter/submittedBefore time range.

For example, this request returns denied claims submitted since January 1:

curl --request GET \
  --url "https://claims.us.stedi.com/2025-03-07/claims?status=DENIED&submittedAfter=2026-01-01T00:00:00Z" \
  --header 'Authorization: <api-key>'

You can page through responses using token-based pagination. Responses include a nextPageToken when more results are available. The pageSize parameter defaults to 100 claim records, up to a maximum of 500.

Claim timeline

The Retrieve Claim Timeline API endpoint returns one entry per event in the claim's history, newest first. Each entry holds exactly one property, and the property name tells you the entry type:

• professionalClaimSubmission, institutionalClaimSubmission, or dentalClaimSubmission – A submission or resubmission.
• claimAcknowledgment – A 277CA claim acknowledgment from Stedi or the payer.
• claimPaymentInformation – A claim payment information record from an ERA.

A resubmitted claim carries every attempt on one timeline, along with the acknowledgments and payments tied to each attempt.

SDK support

The Stedi TypeScript and Python SDKs include operations that cover the three Claims Lifecycle API endpoints.

Availability and pricing

The Claims Lifecycle API endpoints are available on all Stedi production accounts. Claim retrieval is free.

For more details, see our announcement blog.

Introducing the CMS-1500 Professional Claim API endpoints

You can now submit, validate, and retrieve 837P professional claims through JSON API endpoints that mirror the CMS-1500 paper form.

The CMS-1500 – also called the HCFA form – is the standard paper form for professional claims. Every box on the form has a number. Many billers know these numbers. Payers cite them in their own guides. And many AI agents are trained on them.

Until now, only the Stedi portal's professional claim form mirrored the CMS-1500. Our JSON 837P Professional Claim Submission endpoint uses a separate schema.

Now developers and AI agents can apply what they know about the CMS-1500 to Stedi's API. The new endpoints are the same ones that power Stedi's own claim form.

Important: We're not deprecating the JSON 837P Professional Claim Submission endpoint or any other functionality as part of this release. Your existing integrations will continue working.

Watch the 2026 Stedi Keynote announcement:

Request shapes

The new endpoints group fields the same way the CMS-1500 form does. The API reference includes the box number for most fields.

For example, Box 24 – Service lines of the CMS-1500 form is the grid where you list each service you bill. One row of that grid is one object in the serviceLines array.

Test mode support

You can use the Create Professional Claim (CMS-1500) JSON and Retrieve Professional Claim (CMS-1500) JSON endpoints in test mode. You need a test API key for a Stedi production account.

The Validate Professional Claim (CMS-1500) JSON endpoint is not supported in test mode.

Sandbox accounts can't use the CMS-1500 endpoints. To submit test claims, upgrade to a production account.

Limitations

The CMS-1500 endpoints don't support claims for non-primary payers, such as a secondary payer, when the patient is covered by more than one insurance plan. To submit a professional claim to a non-primary payer, use the JSON 837P Professional Claim Submission endpoint, Raw X12 837P Professional Claim Submission endpoint, or SFTP instead.

Availability and pricing

The CMS-1500 endpoints are available on all Stedi production accounts.

Claim retrieval is free. Test claim submissions are free. Production claim submissions and validations are priced per transaction. For pricing, see our Pricing page.

For more details, see our announcement blog.

Introducing the Stedi TypeScript and Python SDKs

We're releasing official software development kits (SDKs) for TypeScript and Python. The SDK packages are available from npm and PyPI.

Previously, Stedi only offered REST APIs. If you wanted language-specific types, retries, or error handling, you had to write your own client. Every customer who integrated with Stedi had to repeat that work.

Now the SDKs do that work for you. You get types, retries, and error handling as part of the SDKs. You only need to write the parts that are specific to your product.

This initial SDK release includes operations covering the following API endpoints:

• The redesigned JSON Real-Time Eligibility Check API endpoint
• CMS-1500 Professional Claim API endpoints
• Claims Lifecycle API endpoints
• Event Destination API endpoints

Watch the 2026 Stedi Keynote announcement:

Get started

Visit the npm and PyPI pages for installation and quickstart instructions.

You'll find runnable, end-to-end examples for every operation in the examples/ directories:

• TypeScript examples
• Python examples

Versioning

The SDKs are generated from our own internal API models, so they stay in lockstep with our REST APIs.

We keep the SDKs backwards compatible within a major version. These changes don't require a new major version:

• New API operations
• New optional parameters
• New fields in responses
• A change in the order of response properties
• A mandatory parameter that becomes optional

A breaking change gets a new major version. Previous major versions keep working, but we recommend that you upgrade.

Try Stedi for free

To use the SDKs, you must have a Stedi API key.

To get started, sign up for a free sandbox account. It takes less than two minutes. No credit card is required.

With a sandbox account, you can create a test API key to run predefined mock eligibility checks or set up event destinations.

When you're ready, upgrade to production on our pay-as-you-go plan. There are no monthly minimums or setup fees. You only pay for the transactions you use.

For more details, see our announcement blog.

Paper claims now support dental claims, attachments, and delivery tracking

We're releasing several major improvements that introduce first-class support for paper claim submissions. You can now:

• Submit dental claims (ADA dental claim form) as paper claims.
• Send 275 claim attachments with paper claims.
• Track a paper claim's print status in the Stedi portal's claims view.
• View a PDF proof of the printed claim package in the Stedi portal.

With paper claims, Stedi prints and mails the claim to any payer for you. You submit them through the same Stedi APIs, SFTP, and Stedi portal UIs you use for electronic claims.

Previously, paper claims covered only professional (CMS-1500) and institutional (UB-04) claims. Attachments weren't supported. You got one 277CA claim acknowledgment when Stedi forwarded the claim for printing. Nothing told you whether the claim reached the mail.

Watch the 2026 Stedi Keynote announcement:

Submit dental paper claims

You can now submit dental claims as paper claims using the following methods:

• JSON API
• Raw X12 API
• SFTP
• X12 upload in the Stedi portal

Attachments for paper claims

You can now submit unsolicited 275 claim attachments as images or PDFs for paper claims using Stedi's claim form UI (professional claims only), JSON API, or SFTP – the same way you would for an electronic claim.

Stedi pairs the claim with the attachment, prints both, and mails them to the payer together.

Track paper claims

The Stedi portal's claims view now follows each paper claim through print and mail. The claim's timeline adds a row for each print stage, newest first.

The claims list shows the same status as an icon in the Status column. You can also filter the list by print status.

277CA claim acknowledgments

A paper claim ends in one of two stages. Stedi returns a 277CA claim acknowledgment for each one:

The earlier print stages don't produce a 277CA. You track those in the claims view.

Download PDF proofs

Every printed paper claim now has a PDF of the claim package, including the printed form and any attachment pages. The Printed row in the claim's timeline holds the file.

Availability and pricing

Paper claims are available on all Stedi production accounts.

Stedi charges for paper claims per page printed and mailed. The page count depends on the claim type, its service line count, and any attachments.

A claim spills onto additional pages when its service lines exceed what one form holds. Attachment pages count the same way.

See stedi.com/pricing for per-page rates.

For more details, see our announcement blog.

Claim edit: ICD-9 qualifier after the ICD-10 transition date

Stedi now rejects 837P professional and 837I institutional claims that declare ICD-9 for a service provided on or after October 1, 2015.

ICD-9 qualifiers and service dates

On October 1, 2015, the U.S. healthcare system replaced ICD-9 with ICD-10. Both the diagnosis code sets and the inpatient procedure code sets changed on that date. A payer won't accept a claim that declares ICD-9 for a service on or after that date.

A claim declares its code set with a code list qualifier. The qualifier sits in a Health Care Code Information (HI) segment in Loop 2300, and it introduces the code that follows it. Each HI segment holds up to 12 composites, so a qualifier can also appear in HI02-1 through HI12-1.

Clinical Modification (CM) diagnosis qualifiers in 837P professional claims

Clinical Modification (CM) diagnosis qualifiers in 837I institutional claims

Procedure Coding System (PCS) qualifiers in 837I institutional claims

The edit compares the qualifier against a governing date. A date of injury governs when the claim carries one. ICD-9 stays valid for an injury that predates the transition, even when the services came later. Otherwise each service line's own date of service governs.

Date of service

Date of injury

A service date is required on every 837P service line. On an 837I claim it's optional, so the edit falls back to the claim statement date in claimInformation.claimDateInformation.statementEndDate (DTP-03 of Loop 2300 with qualifier 434).

How the edit works

If a claim uses an ICD-9 qualifier and a governing date falls on or after October 1, 2015, the payer may reject the claim.

837D dental claims don't carry ICD-9 qualifiers, so this edit doesn't apply to them.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid ICD-9 Qualifier usage. A code list qualifier indicating ICD-9 can not be used for service dates after 09-30-2015. Submitted qualifier(s): BK. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

The error names every distinct ICD-9 qualifier on the claim.

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>508*[DATE]*U*[AMOUNT]******A7>488**Invalid ICD-9 Qualifier usage. A code list qualifier indicating ICD-9 can not be used for service dates after 09-30-2015. Submitted qualifier(s): BK. Correct and resubmit.~

Resolution tips

This edit checks the qualifier. It doesn't check the code the qualifier introduces. To resolve a rejection, change the qualifier to its ICD-10 counterpart, change the code to an ICD-10 code, or change both.

Related claim edits

Stedi has a mirror edit for the opposite mismatch, an ICD-10 code paired with a service date before the transition. See ICD-10 diagnosis code with pre-implementation service date.

Introducing Event Destination API endpoints

You can now create and manage event destinations using the Event Destination API endpoints:

Previously, you had to use the Stedi portal to manage event destinations or rotate signing secrets. Now, you can also do both programmatically from an application or script.

If you're a Stedi app developer, you can use these API endpoints to configure event destinations for your providers' accounts.

The new endpoints are available for free on all Stedi production accounts. For more details, see our announcement blog.

Claim edit: Missing organization name

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include a non-person entity with no organization name.

Entity types and organization names

In a claim, each entity, such as the billing provider or submitter, is identified as either a person or a non-person using an entity type qualifier. Non-person entities include hospitals, billing organizations, and similar groups.

X12 standards require the organization name when an entity is a non-person. In X12, this is the entity's NM1-03 element. If the organization name is missing, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

How entity type qualifiers are specified

If you use Stedi's JSON Claim Submission API endpoints, Stedi sometimes infers the entity type qualifier. For example, if you provide an organizationName for the billing provider in a JSON 837P Professional Claims API request, the entity is treated as a non-person.

If you provide a firstName and lastName, the entity is treated as a person. Other entities, such as otherPayerBillingProvider, have an explicit entityTypeQualifier field.

If you use X12, you set the entity type qualifier in NM1-02 (Entity Type Qualifier). 1 indicates a person and 2 indicates a non-person entity, such as a hospital or billing organization.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Organizational Name. The organizational name is required when Billing Provider is reported as a non-person by the entity type qualifier 2. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, entity identifier code, and error message:

STC*A6>125>85*[DATE]*U*[AMOUNT]********Missing Organizational Name. The organizational name is required when Billing Provider is reported as a non-person by the entity type qualifier 2. Correct and resubmit.~

Related claim edits

Stedi has companion edits for missing person names. See Claim edit: Missing last name and Claim edit: Missing first name.

Stedi also has an edit for person name fields sent on a non-person entity. See Claim edit: Invalid name for a non-person entity.

Claim edit: Missing patient control number

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that don't include a patient control number.

Patient control numbers

A patient control number (PCN) is the tracking ID submitters assign to a claim when they submit it. The payer returns the PCN in follow-up transactions – 277CA claim acknowledgments, Electronic Remittance Advice (ERAs), and claim status checks. You use the PCN to match each response to the original claim.

Patient control number

How the edit works

X12 standards require a PCN on every claim. If you submit a claim without a PCN, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Patient Control Number. A patient control number is required and must be 20 characters or fewer. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A6>481*[DATE]*U*[AMOUNT]********Missing Patient Control Number. A patient control number is required and must be 20 characters or fewer. Correct and resubmit.~

Related claim edits

Stedi has another edit for PCNs longer than 20 characters. See Invalid patient control number.

Introducing the Overview tab for 999 acknowledgments in the Stedi portal

You can now review 999 Implementation Acknowledgments in a new Overview tab on the Stedi portal's Transactions page. The tab shows which transaction sets Stedi accepted, which it rejected, and why, in a human-readable format.

Previously, with only X12 and JSON tabs, you had to locate the AK9 and IK5 segments yourself and look up each error code in the implementation guide.

The Overview tab shows:

• The functional group's identifier, control number, and acknowledgment code, plus how many transaction sets Stedi received and how many it accepted.

• A section for each transaction set, with its control number and acknowledgment code.

• For each rejected transaction set, a table of errors listing the X12 address, the error code, and the value that failed validation.

A 999 confirms X12 syntax only. To verify whether the payer accepted your claim, check the 277CA claim acknowledgment.

For more information, see our 999 acknowledgment docs.