You can now find records and open pages from one search field in the Stedi portal.
Previously, the find-by-ID search only opened a record from its exact ID. To find records by other values, like an NPI, you filtered each list page. Now, one search checks those filters across your list pages at once.
To open the search, press Cmd+K on Mac or Ctrl+K on Windows. You can also click the search field under the account menu in the sidebar.
You can type a page name to go to that page. For example, new check opens the form for a new eligibility check. You can also paste a record ID to search for that record.
To search records, type a value like a provider's NPI. The search shows how many records match in each product your account can use, such as claims, ERAs, or eligibility checks. Each result opens the list page with that filter applied.
ERAs – Trace number, PCN, or payee name, NPI, or tax ID
Payments – ACH trace number, reassociation trace number, or check number
Enrollments – Enrollment ID, provider NPI or tax ID, payer name or ID, or user email
Transactions – Words in the content or control numbers (transaction or functional group)
Most searches need the whole value, like a full NPI or member ID. Eligibility check and eligibility search results only cover the last month. To find older results, adjust the date filter on the list page.
Coverage status – A banner at the top of each coverage shows its number and status.
Filterable benefits table – Each coverage uses the benefits table and filters from eligibility checks, so you can narrow the list to the benefits you need.
Active coverage first – The page opens on the first active coverage, when there is one.
Coverage navigation – A dropdown in the header switches between coverages when the check finds more than one.
CLM05-03 (Claim Frequency Type Code) of Loop 2300 (Claim Information)
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.
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 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.~
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.
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.
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 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" } ]}
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.
REF*G1 (Prior Authorization) of Loop 2400 (Service Line 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.
REF*9F (Referral Number) of Loop 2400 (Service Line 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" } ]}
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.~
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.
REF-02 (Referral Number) of Loop 2400 (Service Line 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" } ]}
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.~
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.
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.
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.
Member ID prefix
Paid amount
Adjustments
STEDI_PAID_, or no prefix at all
Full billed charge
None
STEDI_PARTIALLY_PAID_
60% of billed charge
20% of the charge as a contractual adjustment (reason code 45), 20% as patient responsibility (reason code 2)
STEDI_DENIED_
$0
The full charge as a contractual adjustment (reason code 31)
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.
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.
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.
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" } ]}
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
Create one or more billing entities for the provider.
Link each billing entity to an external bank account.
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.
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.
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.
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.
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.
