Stedi vs Availity vs Optum vs Waystar vs Claim.MD APIs 2026

For most digital health teams with their own engineers, Stedi is the fastest way to start eligibility checks and claims in 2026, because, of the three large vendors, it is the only one that publishes its prices, offers a free self-serve sandbox, and shows its payer coverage and enrollment rules in public. Optum suits teams that need its broad catalog, including prior authorization APIs, and can work through a sales process. Waystar fits vendors selling into hospitals and large groups that already run it. Claim.MD is the low-cost choice for small practices and small teams. Availity matters most because many payers send providers to it, and its new developer platform, Availity Extend, is still in limited access. We checked each vendor's own pages on November 9, 2026, and read eight years of builder discussion to see what teams actually chose and why. Claim.MD also publishes its prices, and we compare it in full below.

A disclosure first. Nirmitee is listed on Stedi's Implementation Partners page, and we build Stedi integrations for clients. We also build on other clearinghouses and EDI routes. Every vendor fact below links to that vendor's own page, every gap is marked, and we say where Stedi is the wrong choice.

This guide is for CTOs, product leads and engineers at telehealth companies, virtual care groups, RCM and billing platforms, practice management and EHR products, and care management companies. It covers what each vendor offers, prices, payer coverage, enrollment, developer experience, the 2024 Change Healthcare outage and what it means for your design, how eligibility responses really behave, edge cases, testing, and a build plan. It is written mainly for software builders. If you run revenue cycle at a hospital, read the Waystar and Optum sections and the note for hospital teams. If you want a team to build it, see our payer and clearinghouse integration services.

The short answer: which one should you pick?

What these APIs do, in plain terms

A clearinghouse is a company that passes standard insurance transactions between providers and health plans. US law (HIPAA) requires these transactions in a format called X12 version 5010. An API vendor wraps those X12 messages in modern JSON web APIs, so your engineers do not write X12 by hand. The transactions that matter most are these.

One timing rule matters for product design. The CAQH CORE operating rules for eligibility say a real-time 270 must get its response within 20 seconds. Design your screens to wait that long, and to show a useful state while they wait.

Side by side: Stedi, Availity, Optum, Waystar and Claim.MD

Every fact below comes from the vendor's own pages, read on November 9, 2026. "Not published" means we did not find it on the vendor's public pages, not that the feature is missing.

Security is not in the table, because we could not check every vendor the same way. Ask each one for its SOC 2 or HITRUST report and a signed BAA (business associate agreement, the HIPAA contract for handling patient data). Stedi posts its reports at its trust center. Waystar shows HITRUST, SOC 2 and PCI DSS badges, and Claim.MD reports HITRUST r2, SOC 2 Type 2 and EHNAC accreditation. We did not find a security page for Availity or Optum in this check.

Who should use each one, and who should not

No single vendor is best for everyone. This is our fair read of where each one fits, based on its own published pages and on what builders reported in the community. Where a point is our judgment, we say why.

Our own position again: we are a listed Stedi implementation partner, so read the Stedi row with that in mind. We have tried to list its limits as plainly as the others'.

Stedi in depth

Stedi describes itself as built for teams with in-house engineers who want to build their own RCM stack on its clearinghouse APIs. Its public pages are the most complete of the five on prices, payer coverage and enrollment. Optum's API catalog is wider.

Payer coverage you can check before you sign

Stedi's Payer Network page is public and searchable. On November 9, 2026 it listed 3,683 payers in total. The total counts every payer for any transaction, so look at the number for the transaction you need: 1,289 payers for eligibility checks, 76 for coordination of benefits checks, about 3,102 for claim submission (Stedi shows this one as approximate), 3,102 for claim acknowledgments, 2,509 for electronic remittance, 529 for electronic funds transfer and 774 for ERA plus EFT together. For a startup that needs eligibility first, 1,289 is the number that matters. Each payer row shows which transactions it supports and whether enrollment is needed. You can download the list as a CSV, and a Payers API returns the same data in JSON, with search by name, payer ID or alias. Stedi suggests refreshing cached payer data daily.

Payer ID aliases matter more than they look. A payer may be known by dozens of IDs and names. The network page shows, for example, 65 other names for Centene and 64 for UnitedHealthcare. Aliases let old payer IDs keep working, and route plan-specific IDs to one payer. Store the payer's primary ID separately from the alias your users typed.

Prices

Stedi's pricing page, read on November 9, 2026, lists three plans: a free sandbox, pay as you go with no monthly minimum, and custom pricing for volume. Stedi says there is no monthly minimum, no per-provider fee and no per-payer fee. Prices fall by monthly volume, and each unit is billed at the price of the tier it falls into. So your first 250 eligibility checks in a month cost $0.30 each, and checks 251 to 3,500 cost $0.15 each.

Flat prices: claim attachments $0.75, workers' compensation and auto claims $0.30, eligibility, claim and ERA PDFs $0.05, claim validations $0.05, paper claims $1.00 for the first page and $0.20 after. Claim acknowledgments (277CA), the payers API, the enrollment API, test mode and support are free.

Fees a payer charges are passed through at cost. In community threads from earlier years, members quoted a monthly minimum for Stedi, and a software directory still lists a higher starting price. Both are out of date against the current pricing page, which says pay as you go has no monthly minimum. Always check the live page before you model costs.

Developer experience

• Sandbox. Free sign-up, test API keys and mock eligibility checks. The portal includes predefined mock requests for Aetna, Cigna, UnitedHealthcare and CMS.
• APIs and formats. JSON APIs for eligibility and claims, raw X12 endpoints, SFTP, webhooks and an MCP server for AI tools. The legacy JSON eligibility endpoint uses the path /change/medicalnetwork/eligibility/v3, which mirrors Change Healthcare's own JSON API, so teams moving from Change can reuse much of their request shape. Stedi recommends its newer JSON endpoint for new builds.
• Errors you can act on. Error responses include the raw X12 so you can read a 999 rejection yourself.
• Prior authorization checks. Stedi's docs explain how to read the eligibility response to see whether prior authorization or a referral is required for a service. Submitting the authorization itself (a 278) is not in its docs.
• Support. Slack, Teams and email, with a stated average response under 10 minutes.

Enrollment

Transaction enrollment is the payer's approval for a provider to use a transaction through a clearinghouse. Stedi's docs say every payer requires enrollment for 835 ERAs, and other transactions vary by payer: the API marks each as supported, enrollment required, or not supported. Most enrollments finish in 24 to 48 hours, and some payers take up to 30 days. Enrollment statuses run from draft through provider action required and provisioning to live, rejected or canceled, which you can show in your own product.

ERA enrollment is exclusive: a provider and tax ID can receive 835s through one clearinghouse at a time for a payer. Moving ERAs to Stedi stops them arriving at your old clearinghouse. Plan the cutover date with the provider's billing team.

Stedi links: pricing, payer network, eligibility docs, transaction enrollment, eligibility troubleshooting.

When Stedi is the wrong choice

• You have no engineers and want a finished billing product. Stedi says itself it is not always the right fit, and points such teams to platforms in its Platform Partners directory.
• You need to submit prior authorizations (278) through the same vendor. Stedi's docs cover checking whether authorization is required, from the eligibility response, but not submitting the request.
• Your key payers are not among the 1,289 that support eligibility through Stedi. Check them on the payer network page before you build.
• Your payers require Availity for enrollment or authorizations. You will use Availity's portal either way.

Availity in depth

Availity is a clearinghouse and health information network, and it is two things that are easy to mix up. Availity Essentials is the provider portal: staff log in to check eligibility, submit claims, track ERAs and handle payer workflows. Its sign-in page promises free, real-time access to hundreds of payers. Availity's developer APIs are the programmatic side, and they are in the middle of a move.

The developer program is moving to Availity Extend

On November 9, 2026, Availity's developer portal said it still serves existing applications and API subscriptions, that Availity Extend is its new developer experience, and that general availability begins in mid-November 2026. Extend's own site showed a "Limited Access" banner that day, saying it is available to select organizations, and its pricing link led to an Availity login. Extend's home page states more than 500,000 active providers, more than 6,000 hospitals connected, a 99.9% uptime SLA and coverage in more than 50 states. For a new team: ask Availity for Extend access and pricing in writing, and check again after general availability.

The current developer portal names these API families: HIPAA transaction APIs, Enhanced Claim Status, Service Reviews add-on APIs, eligibility and benefits value-add APIs, a Claim Attachments API and a Remittance Data API in beta. It does not publish how each family maps to X12 transactions, the sandbox terms, rate limits or prices.

Availity links: developer portal, Availity Extend, eligibility and coverage, Essentials Plus.

Why Availity still matters even if you use another API

• Payers send providers there. Payers publish their own Availity guides. For example, AvMed's provider quick guide says it charges no Availity fees from January 1, 2026, and MVP Health Care announced it would move provider workflows to Availity from July 20, 2026. Your provider customers may need an Availity account whatever API you choose.
• Essentials is free for sponsored payers. Availity says Essentials is free for payers that sponsor it, and Essentials Plus extends to other payers for a fee.
• Payer lists by product. Availity's site links separate payer lists for Essentials, Essentials Pro and its CMS-0057-F (prior authorization API rule) offering, without a single total.
• Community experience. In the Health Tech Nerds threads we read, builders often described Availity as something payers require for enrollment or authorizations, even when claims go elsewhere. One member said the Availity eligibility API was not fully real-time for their use and returned only part of the X12 fields. One practice said waiting for an Availity account delayed its move in-network. These are individual reports, not measured results.

Optum in depth

Optum, part of UnitedHealth Group, owns Change Healthcare and runs the Optum medical network APIs. Its developer portal has the widest public catalog of the three.

What Optum publishes

• Eligibility V3 and Enhanced Eligibility, with mock scenarios in the sandbox.
• Professional Claims V3 and Institutional Claims V1. Optum's description says the professional claims API translates the X12 837P into JSON.
• Claim Status V2 and Claim Responses and Reports V2 for 277 and 835 responses.
• Attachments submission, retrieval and status, including 275 for prior authorization and dental attachments.
• Prior Authorization V1 and a prior authorization FHIR hub with clinical data exchange and coverage requirements discovery.
• PayerList V1, with a CSV download and payer outage pages.

Each API has a page mapping its JSON fields to X12. Authentication uses bearer tokens. A sandbox account comes with predefined test values. Optum's business site says it connects to 2,400 payers. It does not publish API prices. Its marketplace lists sandbox access and trials, and production pricing comes through sales.

Optum links: API developer portal, marketplace, medical EDI, Intelligent EDI.

The 2024 Change Healthcare cyberattack

Any clearinghouse decision made since 2024 has to account for what happened in February of that year.

Optum says its Intelligent EDI (iEDI) platform was built outside the Change Healthcare environment, was not affected, and that former Change connections were moved to it.

In the Health Tech Nerds threads, the outage period (February to May 2024) produced the clearest lessons. Members described claims they could not send, thousands of 835 files to reconcile by hand, and questions about breach notices before affected patients were known. Teams asked who had moved from Change to Stedi, and one moved claims to Claim.MD for a time. The lesson most of them drew was to keep a second route ready. Mentions of Change Healthcare in the threads fell sharply after 2024, while mentions of Stedi rose. Many Stedi mentions come from Stedi's own staff, so treat that only as a rough sign of attention, not of market share.

Already on Change Healthcare or Optum? Adding a second route

Most platforms that came through 2024 on Change did not leave Optum. They added a second route. A workable order:

1. Ask Optum about Intelligent EDI. If you are still on older Change Healthcare connections, ask which of your transactions run on iEDI today and on what terms.
2. Add eligibility on a second vendor first. It needs the least enrollment and can fail over in real time. Run both side by side on a sample of patients and compare the answers.
3. Pick a test group for claims. Move claims for one or two practices or payers to the second route, with their own ERA enrollment, and reconcile for a full billing cycle.
4. Decide the long-term split by payer. Some teams keep each payer's claims and ERAs on the route that performs best for that payer, and keep eligibility on both.
5. Write down the outage plan. Which transactions move, who approves the move, and how ERAs and payments are reconciled while one route is down.

For a platform with many practices, enrollment is the main cost in staff time, because ERA enrollment is per provider, tax ID and payer. Ask each vendor whether it handles enrollment paperwork for you, and whether it offers bulk enrollment through its API. Stedi and Claim.MD both offer enrollment through their APIs.

Waystar in depth

Waystar is a large revenue cycle platform, used mostly by hospitals, health systems and large physician groups. Its about page, read on November 9, 2026, says it connects to more than 5,000 payers, serves more than 30,000 clients and handles 7.5 billion transactions a year. It became a public company in June 2024, when its IPO priced at $21.50 a share on Nasdaq under the ticker WAY, and it closed its acquisition of Iodine Software, a clinical documentation company, on October 1, 2025.

What Waystar publishes for developers

• A developer portal at developer.waystar.com that lists REST APIs, web services, SFTP, HL7, X12 and bots.
• Products for eligibility, coverage detection (finding insurance a patient did not mention), prior authorization, claims, attachments and remittances.
• Pages for a sandbox and for HMAC request signing, which we could not read without an account.
• HITRUST, SOC 2, PCI DSS and HIPAA badges on its site.

The public portal also lists test and sandbox accounts, a payer ID list and HMAC signing pages, so you can see the API areas before you talk to sales. To get access, you register on the portal and then sign a contract. Waystar also says it has more than 500 EHR and practice management integrations. It does not publish prices.

Community comments about Waystar in the threads we read were mostly from before 2022, covering multi-year contracts and limited raw EDI access. We give them little weight, because they may not reflect the platform today. In our own Waystar integration work, the details that most often need care are telling a 277 claim status response from a 277CA acknowledgment, sending 276 status requests on a schedule, and parsing CAS adjustment segments in 835s. These apply to other clearinghouses too, but Waystar's documentation for them sits behind the portal login.

Waystar links: developer portal, about Waystar.

When Waystar fits

Waystar fits when you sell into hospitals and large groups that already use it, or when you need its broader revenue cycle products alongside the transactions. For a startup that wants to start this month with published prices, it is usually the slower path.

A note for hospital revenue cycle teams

If your hospital already runs Waystar, this comparison is not a reason to switch. Institutional claims (837I, the electronic UB-04), secondary claims and denial management are where an enterprise platform earns its cost, and your EHR's billing build is tied to it. What the 2024 outage does suggest is a backup for eligibility checks, so registration staff can keep checking coverage if one route goes down. Ask your EHR team which eligibility routes your EHR supports, and test a second one before you need it.

Claim.MD in depth

Claim.MD is a clearinghouse popular with small practices and small software teams, because its prices are public and low. It publishes an API reference at api.claim.md.

Prices, as published

The pricing page lists no setup fee and no per-provider fee. Plans are priced per billing tax ID, and one tax ID is included. Extra tax IDs cost from $30 a month on Unlimited down to $6 a month on Basic. Over the included amounts, Unlimited charges $0.02 per eligibility check for prime payers and $0.10 for others. Basic charges $0.30 per claim, ERA or eligibility check, and Small Volume charges $0.50 past its 100. Attachments are $0.60 each, and paper or faxed claims are $1.00 for up to five pages. The page does not say whether API access is included in every plan, so ask before you build.

Claim.MD links: pricing, payer list, API reference.

The API, in brief

• Style. Form-encoded POST requests that return XML or JSON, plus file upload for batch claims in 837, CSV, JSON, XML or spreadsheet formats. It is not a JSON REST API in the modern sense.
• Limits. The reference says calls should not exceed 100 requests per minute. Up to 2,000 claims can go in one upload.
• Transactions. Claims (837P and 837I), eligibility (270/271), ERAs as X12, PDF or JSON, a payer list, provider enrollment requests and claim appeals. Claim.MD documents the X12 277 claim status file over SFTP. We did not find 837D, 278 or 275 in the API reference.
• Webhooks. For enrollment and appeal events. Plan to poll for ERAs.
• Testing. Test accounts come from Claim.MD and do not convert to production, so you set up the production account and its payer enrollments separately.
• Security. Claim.MD reports HITRUST r2 certification, SOC 2 Type 2 and EHNAC accreditation.

In the community threads, builders chose Claim.MD for price, simplicity and helpful support. Complaints were limited support capacity and a provider check that took more than a week. In 2026 one team was weighing a move from Claim.MD to Stedi for per-transaction pricing.

Other options worth a line

• pVerify (API developers) focuses on eligibility and insurance verification, with an API developer hub. Its API pricing page showed no numbers when we checked.
• Office Ally is a low-cost clearinghouse widely used by small practices. We did not find its prices on its own pages.
• Candid Health (site) is a claims and billing platform built for digital health companies, mentioned often in the community as an alternative to building claims yourself.

What it costs: three worked examples

These examples use only the prices Stedi and Claim.MD publish. Availity, Optum and Waystar are left out because they do not publish prices. Stedi bills each unit at the rate of the tier it falls into, so the first 500 claims in a month cost $0.30 each, the next 2,000 cost $0.20, and so on. Claim.MD charges a monthly plan per tax ID plus overage fees. These are examples from public price lists, not quotes, and payer-specific fees are extra.

On published list prices, Claim.MD is cheaper in all three examples. Stedi's case rests on other things: no tax ID fees as you add practices, a free self-serve sandbox, JSON APIs with webhooks, coordination of benefits and insurance discovery, larger published payer coverage, and support response times. Whether those are worth the difference depends on how much engineering and support time they save you. Two cautions on the Claim.MD figures: we assumed the 1,000 included eligibility checks apply once per account, and the page does not say whether API access is included in every plan. Confirm both with Claim.MD before you rely on this.

At higher volume Stedi's rates keep falling, to $0.08 to $0.10 per transaction above 10,000 a month, and Stedi offers custom pricing. Run your own volumes through each vendor's live pricing before you choose.

What an eligibility response really tells you

For the X12 detail behind this section, see our guides to 270/271 eligibility in production and US payer integration for eligibility, claims and EDI.

A 271 response says whether a patient has active coverage on a date, and lists benefits by service type. It does not promise that a visit will be paid. Builders in the community threads raised the same complaints again and again: deductibles that lag behind claims, network status that is unreliable, and checks that confirm coverage but not whether a specific service is covered. Stedi's own troubleshooting page lists more payer differences:

• Some payers need the member ID, and some refuse checks for dependents.
• Date ranges for the check differ by payer.
• Some payers return only benefits that match the provider's taxonomy, the code for their specialty.
• Medi-Cal and some other payers need a provider PIN.
• Some payers send a 999 rejection instead of a 271.

Stedi also warns against code that matches exact message text, because payers word things differently. So the product should:

1. Show coverage as "active", "inactive" or "could not confirm", with the date and the payer's own words.
2. Show benefits for the service type you asked about, not the whole response.
3. Show the deductible and out-of-pocket amounts with the date they were reported, and say they may lag.
4. Never turn a 271 into a promise of payment in your product's wording.

Errors you must handle

X12 eligibility errors come as AAA codes. Stedi's docs describe how to treat the common ones:

For scheduled checks, Stedi suggests backing off from 1 minute up to 30 minutes, for at least 8 hours.

Claim status: how each vendor tells you where a claim is

After a claim leaves, four kinds of responses tell you where it is. Your product should track each one separately, because each answers a different question.

A rejection at the 277CA stage means the claim never entered processing. Fix it and send it again. A denial in a 277 or 835 means the payer processed it and said no, so it needs a corrected claim or an appeal. Keep these in separate work queues.

Claim status by vendor

Prior authorization numbers on claims

Prior authorization shows up in two places in this workflow. Before the visit, the eligibility response can show whether a service needs prior authorization or a referral. Stedi's docs explain how to read this from the 271 benefits. After the visit, the claim carries the authorization number. Since October 21, 2026, Stedi rejects 837P and 837D claims that report more than one prior authorization or referral number on a service line for the destination payer. To report another payer's number, such as the primary payer's on a secondary claim, include that payer's identifier. Build this check into your own claim validation too, whichever vendor you use.

Design: one interface, two routes

The 2024 outage taught the community one thing above all: keep a second route ready. That does not mean paying two vendors for everything. It means building your product against your own interface, so switching or splitting traffic is a configuration change.

// Illustrative design, not any vendor's SDK.
interface ClearinghouseAdapter {
  name: "stedi" | "availity" | "optum" | "waystar" | "claimmd";
  checkEligibility(req: EligibilityRequest): Promise<EligibilityResult>;
  submitClaim(claim: Claim): Promise<SubmissionReceipt>;
  claimStatus(ref: ClaimRef): Promise<ClaimStatus>;
  listRemittances(since: Date): Promise<Remittance[]>;   // 835s, if this vendor holds ERA enrollment
  payerSupport(payerId: string): Promise<PayerCapabilities>;
}

type EligibilityResult = {
  status: "active" | "inactive" | "unknown";
  checkedAt: string; payerId: string; rawX12?: string;   // keep the raw response for support
  benefits: Benefit[]; errors: { aaa: string; retry: boolean }[];
};

async function checkWithFallback(req: EligibilityRequest, primary: ClearinghouseAdapter,
                                 backup?: ClearinghouseAdapter): Promise<EligibilityResult> {
  const r = await primary.checkEligibility(req);
  const retryable = r.errors.some(e => e.retry);
  if (r.status === "unknown" && retryable && backup) return backup.checkEligibility(req);
  return r;
}

Three rules make this work in practice.

• Eligibility can fail over. ERAs cannot. Eligibility checks can go through a backup at once. ERA enrollment is exclusive to one clearinghouse per provider, tax ID and payer, so a second vendor cannot simply read your 835s. Plan an ERA cutover as a dated project.
• Keep your own payer table. Map each payer to its ID at each vendor, what it supports, and enrollment status. Vendors use different payer IDs and aliases.
• Store raw responses. Keep the raw X12 or vendor response for each transaction, out of your logs, so support can answer "what did the payer say" months later.

Switching clearinghouses

If Waystar is your current or target route, our Waystar clearinghouse integration guide covers its 277 and 835 details.

1. Export your payer and enrollment list from the current vendor: every payer, provider and transaction you use.
2. Map payer IDs to the new vendor's IDs and aliases.
3. Move eligibility first. It needs the least enrollment and is easy to compare side by side.
4. Enroll claims and ERAs with the new vendor. Stedi says most enrollments finish in 24 to 48 hours and some take up to 30 days. Claim.MD says one-click eligibility enrollment is active within 24 to 48 hours.
5. Set the ERA cutover date with each provider's billing team, because ERAs stop at the old clearinghouse when the new enrollment goes live.
6. Run both for one billing cycle and reconcile claims, acknowledgments and remittances before you turn the old route off.

Edge cases that break eligibility and claims products

How to test before you go live

Who needs an eligibility and claims API: 8 use cases

Questions to ask every vendor before you sign

1. Which of our top 20 payers support eligibility, claims, claim status and ERAs through you, and which need enrollment?
2. How long does ERA enrollment take for those payers, and who does the paperwork?
3. What is the published price per transaction, the monthly minimum and the fee for extra tax IDs or providers?
4. Can we test in a sandbox today, without a contract?
5. Do you return raw X12 as well as JSON?
6. What are your rate limits, and how do you signal them?
7. Do you send webhooks for 277CA, claim status and 835s, or must we poll?
8. How did your service perform during the February 2024 Change Healthcare outage?
9. Will you sign a BAA, and what security reports can you share?
10. How do we leave? Can we export enrollments and payer mappings?

A build plan

Where Nirmitee fits

Nirmitee is a healthcare product engineering company, and Stedi lists us on its Implementation Partners page. In Stedi's spotlight interview with our co-founder and CEO, Yogesh Daga, published October 7, 2026, he describes what we deliver for teams building with Stedi: API integration, data mapping, screens to review coverage and correct rejected submissions, testing, and an operational handoff. We also build with other clearinghouses and EDI routes when they fit the customer better, and we connect eligibility and claims to EHRs through FHIR and HL7.

What an eligibility and claims gap check gives you

This is the fixed-scope first step we offer. You get a written answer to "which vendor fits our payers and volume, and what do we need to build".

It starts with a 30-minute call, where we confirm the scope and agree a fixed price and delivery date before any work begins. You keep everything we send, whether or not you work with us afterwards. Book a call to scope your eligibility and claims gap check.

Sources

• Stedi pricing, Payer Network, eligibility API reference, supported payers, transaction enrollment and eligibility troubleshooting pages (stedi.com), read November 9, 2026.
• Stedi Implementation Partners page and "Spotlight: Yogesh Daga @ Nirmitee.io", October 7, 2026 (stedi.com).
• Stedi, "Introducing the Stedi Platform Partners directory", July 14, 2025.
• Availity developer portal (developer.availity.com), Availity Extend (build.availity.com), Availity Essentials sign-in page, and Availity's blog on Essentials Plus, read November 9, 2026.
• AvMed Availity provider quick guide, and MVP Health Care's 2026 Availity announcement.
• Optum API developer portal (developer.optum.com), Optum marketplace, Optum business site on EDI connectivity, and UnitedHealth Group pages on Intelligent EDI.
• UnitedHealth Group update on the Change Healthcare cyberattack, March 7, 2024, and Healthcare Dive, January 27, 2025.
• Waystar about page, developer portal (developer.waystar.com) and IPO announcement, June 2024.
• Claim.MD pricing page, payer list and API reference (api.claim.md), read November 9, 2026.
• CAQH CORE Phase I eligibility rule 156 (20-second real-time response).
• Practitioner discussion in the Health Tech Nerds community, 2021 to 2026, anonymized. Thread counts come from a keyword script and include vendor staff posts.