Skip to main content
Real-time processing attempts electronic benefit verification (eBV) for every requested drug. 80% of successful real-time BVs complete within 10 seconds. The electronic attempt has a 30-second deadline. Continue waiting for the webhook or polling the same resource ID. Standard fallback timing depends on the verification method and payer. See the overview for typical timings by method. 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 API is asynchronous: creation returns a benefit verification ID. Read the result with GET /benefit-verification/{id} or receive it through 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 responses from POST /benefit-verification and GET /benefit-verification/{id} include data.current_processing_mode:
Interpret current_processing_mode as follows:
  • realtime means the request is assigned to real-time processing or completed through it.
  • 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. Check GET /benefit-verification/{id} for a cancelled status or a processing-mode change before completion or failure.

​
Fallback behavior

A realtime request continues in standard processing on the same benefit verification when:
  • real-time processing is unavailable for the request;
  • real-time verification cannot return a complete result; or
  • the 30-second deadline 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 responses from GET /benefit-verification/{id} show current_processing_mode: "standard". Continue tracking the same benefit verification ID for the final status and result. A realtime_only request never falls back. If real-time verification is unavailable or cannot complete within 30 seconds, the benefit verification fails.

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

​
Limitations

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