Changelog

Claim edit: Invalid claim frequency code

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims with a claim frequency code that isn't valid for the claim type.

Claim frequency codes

The claim frequency code tells the payer whether a claim is an original claim, a replacement, a void, or another type of submission.

Claim frequency code

The valid codes depend on the claim type:

• 837P professional and 837D dental claims – 1 (Original), 7 (Replacement of Prior Claim), or 8 (Void/Cancel of Prior Claim).
• 837I institutional claims – A National Uniform Billing Committee (NUBC) frequency code, such as 1 (Admit thru Discharge Claim), 7 (Replacement), or 8 (Void).

How the edit works

If a claim uses a code outside this set, 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

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Claim Frequency Code. The submitted frequency code, 6, is not a recognized claim frequency code for this claim type. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>535*[DATE]*U*[AMOUNT]********Invalid Claim Frequency Code. The submitted frequency code, 6, is not a recognized claim frequency code for this claim type. Correct and resubmit.~

Related claim edits

Stedi has another edit for claim frequency codes that conflict with the patient status code. See Invalid claim frequency code and patient status code combination.

Claim edit: Missing billing provider taxonomy code in dental claims

Stedi now rejects 837D dental claims that are missing a billing provider taxonomy code when no rendering provider or assistant surgeon is reported.

How the edit works

A taxonomy code identifies a provider's type and specialty, such as general dentistry or orthodontics.

A dental claim can name a rendering provider or an assistant surgeon for the whole claim or for individual service lines. If the claim names neither at any level, the billing provider is the one who rendered the service. In that case, X12 standards require the claim to include the billing provider's taxonomy code.

Billing provider taxonomy code

If the billing provider taxonomy code 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.

Rejection errors

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Billing Provider taxonomy code. This code is required when no rendering provider or assistant surgeon is reported. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A6>145>85**U*[AMOUNT]******A6>732~

Related claim edits

Stedi has other edits that check the taxonomy code when it's present. See:

• Invalid taxonomy code
• Taxonomy code not in the NUCC code set

Claim edit: Prior authorization number matches the referral number

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that report the same value for the prior authorization number and the referral number.

Prior authorizations and referrals

A prior authorization is the payer's approval of a service before the provider performs it. The payer assigns a number to each approval. You can report the prior authorization number at the claim level or on a service line.

Prior authorization number

Service line prior authorization number

A referral is a provider's recommendation that the patient can see another provider – for example, a primary care provider who sends the patient to a specialist. Some plans, such as HMOs, require a referral before they cover a specialist visit. Each referral has its own number.

Referral number

Service line referral number

How the edit works

A prior authorization and a referral are different approvals, so their numbers shouldn't match. If you submit a claim with the same value in both fields, the payer may reject the claim.

The edit compares the numbers at the claim level and on each service line. When a service line reports only one of the numbers, the edit compares it to the other number at the claim level. The comparison ignores letter case.

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 Prior Authorization number. The prior authorization number, PA20261009, cannot be the same value as the referral number. 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*A8>761>QC*[DATE]*U*[AMOUNT]******A8>252>QC**Invalid Prior Authorization number. The prior authorization number, [PRIOR AUTHORIZATION NUMBER], cannot be the same value as the referral number. Correct and resubmit.~

Related claim edits

Stedi has another edit for service line referral numbers. See Service-line referral number without a claim-level referral number.

Claim edit: Service-line referral number without a claim-level referral number

Stedi now rejects 837P professional claims that report a referral number on a service line but not at the claim level.

Claim-level and service-line referral numbers

A referral number is the number a payer assigns when it approves a referral to another provider. For example, a payer may require a referral before a patient sees a specialist.

You can report the referral number at two levels. The claim-level referral number applies to every service line on the claim.

Claim-level referral number

A service-line referral number applies to a single service line.

Service-line referral number

How the edit works

Per HIPAA standards, the claim-level referral number applies to every service line. You can also report a referral number on a service line when it differs from the claim-level number. Without a claim-level referral number, there's nothing for the line to differ from.

If a claim reports a referral number on a service line but omits the claim-level referral number, 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 Line-Level Referral Number. The service-line referral number on line 1, REF789012, should not be submitted when a claim-level referral number is not present. 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>247*[DATE]*U*[AMOUNT]******A7>761>QC**Invalid Line-Level Referral Number. The service-line referral number on line 1, REF789012, should not be submitted when a claim-level referral number is not present. Correct and resubmit.~

Related claim edits

Stedi has another edit for a referring provider on a service line without one at the claim level. See Missing claim-level referring provider.

Introducing the redesigned eligibility check view

You can now review an eligibility check's result, summary, and benefits on one page in the Stedi portal's checks view.

Previously, each check had separate Overview and Benefits tabs. Plan details and benefit-related entities were on the Overview tab, apart from the benefits they applied to.

Now, the benefits table is part of the Overview tab. The redesign includes:

• Status banner and summary – A banner at the top of the page shows the check's result, above a summary of the check's details.
• Plan details – Plan names, group numbers, plan numbers, and plan dates appear in the benefits table.
• Coverage statuses – Each status has its own Statuses row in the benefits table.
• Related entities column – Benefit-related entities have their own column in the benefits table.
• Benefits filters – The benefits table has 15 filters, up from 7.

For more details, see our announcement blog.

Filter claims by billing provider name in the Stedi portal

You can now filter claims in the Stedi portal's claims view by billing provider name.

Previously, you could only filter by the billing provider's NPI or Tax Identification Number (TIN). Now you can find a provider's claims by name, without looking up an identifier.

The filter supports partial matching, so you can enter part of the provider's name. If a claim has resubmissions, it matches when any of its submissions has a matching billing provider name.

For more information, see our filter claims docs.

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