Skip to main content
Real-time processing attempts electronic benefit verification (eBV) for every requested drug. 80% of successful real-time BVs resolve within 10 seconds. Every real-time attempt completes, falls back, or fails within a maximum of 30 seconds. Real-time capability must be enabled for your organization before you can use it. Contact Develop Health to confirm availability and expected throughput.

​
Choose a processing mode

Set preferred_processing_mode when creating a benefit verification. The field defaults to standard.

​
How real-time processing works

The real-time path selects one eligible electronic route. The API remains asynchronous: creation returns a durable benefit verification ID, and the final result is delivered through the retrieve endpoint or a webhook. A successful real-time result uses the same response fields and completeness requirements as a successful standard result. Lower real-time coverage means that fewer requests qualify for or complete through the fast path, not that successful results contain fewer fields.

​
Track the current processing mode

The create and retrieve responses include the processing family that currently owns the request:
Interpret current_processing_mode as follows:
  • realtime means the real-time eBV attempt is active or produced the terminal result.
  • standard means the full standard benefit verification process owns the request. A request with preferred_processing_mode: "realtime" can return standard immediately or change from realtime to standard after fallback.
The terminal webhook reports the benefit verification when it reaches completed or failed. Handle cancelled from the cancellation response or the retrieve endpoint. Poll the retrieve endpoint when your workflow needs to observe a processing-mode change before the request becomes terminal.

​
Fallback behavior

A realtime request continues in standard processing on the same benefit verification when:
  • the request does not qualify for an eligible real-time electronic route;
  • real-time vendor capacity is unavailable;
  • the selected eBV vendor returns an error or an incomplete result; or
  • the 30-second timeout is reached before every requested drug completes.
Fallback can happen before a real-time attempt starts. The create response then returns current_processing_mode: "standard", and standard processing begins immediately. Fallback can also happen after a real-time attempt starts. Subsequent retrieve responses change from realtime to standard, and a fresh standard attempt begins from the start on the same benefit verification. Standard processing then determines the final status and result. A realtime_only request never falls back. Real-time ineligibility, unavailable capacity, vendor failure, incomplete results, or the 30-second timeout produces a failed benefit verification.

​
Input requirements

Requests for either real-time mode must include an NDC for every requested drug. If any drug omits its NDC, the API rejects the request without creating a benefit verification. The real-time path also requires structured insurance data in insurance_content, including the member number and the Rx BIN, Rx PCN, and Rx group when applicable. Insurance-card images or patient demographics alone do not qualify a request for real-time processing.

​
Insurance-card images

You can send card images together with structured insurance data. The real-time attempt uses the structured data and does not scan the images.
  • If a realtime request falls back, standard processing can scan and use the submitted card images.
  • A realtime_only request does not scan the images because it never enters standard processing.

​
Limitations

  • Real-time processing supports eBV only. It does not use OCR, demographic-only insurance lookup, AI or human phone calls, cross-vendor attempts, or transient vendor retries.
  • Every requested drug must complete before the 30-second timeout. Partial multi-drug results do not count as real-time completion.
  • Coverage varies by patient, plan, pharmacy benefit manager (PBM), drug, and organization configuration.
  • Real-time processing has lower rate limits than standard processing. Available capacity can vary, so realtime requests may fall back and realtime_only requests may fail during traffic bursts.
Contact Develop Health before a material traffic increase to confirm expected real-time throughput for your organization.