One of the hardest problems in healthcare infrastructure is resiliency. Payers go down a lot - planned maintenance, unplanned outages, slow responses, upstream gateway issues, you name it. And until now, providers have largely been in the dark when it happens.

This week we're stepping slightly off the original Flows roadmap to talk about how we've built resilience into Verification, and to introduce a new tool designed to make this behavior visible: the Payer Status dashboard.

Introducing the Payer Status Dashboard

In the Sohar web app you can now view real-time uptime and outage information for 25 high volume payers. Instead of wondering "Is this payer down?" or troubleshooting false failures, you can now see everything in one place - the actual availability and responsiveness of each payer over time.

This transparency helps teams understand whether a delay is coming from the payer, their own systems, or somewhere else in the workflow.

Why Resilience Matters

Most eligibility systems today are built around synchronous calls to payers: make a request, wait for the response, hope the payer is up.

But when that payer is down - which happens more often than most realise - workflows stall, retries multiply and staff are left guessing.

Sohar takes a different approach. Our Verification API is fully asynchronous, which gives us a powerful foundation for resilience. Instead of leaving you to retry or monitor payer availability, Sohar handles all of that behind the scenes, surfacing only meaningful state changes to your system.

The result: a smoother experience for staff and patients, and dramatically reduced operational noise.

How Asynchronous Verification Gives You Reliability

When you submit a Verification request, we immediately return an ID so your app stays responsive. From there, the workflow becomes event-driven:

1. If the payer is available → standard processing

We resolve most verification requests in seconds. Once complete, we send a verification.updated webhook event.

2. If the payer is unavailable → we send an interim alert

When we detect that a payer is down, we return a verification.pending webhook event. This is your signal that processing will take longer, without requiring you to do anything.

3. Sohar automatically retries with exponential backoff

We handle all retries on your behalf. Our retry logic runs for up to 24 hours, spacing retries according to exponential backoff to avoid overloading payers and to give them time to recover.

4. After 24 hours → final resolution

If the payer remains down after 24 hours, we send a final verification.updated event with an error.payer status. This indicates that all retry attempts were exhausted and the payer never recovered within the retry window.

What You Should Do (and Not Do)

One of the most important design principles behind this flow is that you should not retry requests. Sohar handles all retries automatically - retrying on your side creates duplicate requests and unnecessary traffic.

The verification.pending event already tells you the request is in progress. The final verification.updated event cleanly signals when to move forward.

Only after receiving error.payer status should you initiate a new request. This gives you a simple, predictable pattern: trust the async workflow, rely on webhook updates, and only retry after explicit failure.

Why This Matters for Real Workflows

Resilience isn't an edge case - it's a core requirement for modern healthcare applications. The combination of:

  • Asynchronous verification
  • Meaningful webhook updates
  • Automatic retry logic
  • Error transparency
  • Real-time payer uptime visibility

means that your systems stay operational and predictable even when payers aren't. Staff aren't left guessing. Developers don't need to build custom retry schedulers. Patients don't experience silent failures.

By designing the system around real-world payer behaviour - not an idealised version of it - Sohar provides a foundation you can rely on.

‍