> ## Documentation Index > Fetch the complete documentation index at: https://docs.develophealth.ai/llms.txt > Use this file to discover all available pages before exploring further. # Real-Time Processing > Eligibility, processing modes, fallback behavior, and capacity for real-time benefit verification. 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`. | Value | Behavior | Best for | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | `standard` | Uses the full benefit verification process and the broadest available input and completion paths. | Requests where completion rate is more important than latency. | | `realtime` | Attempts real-time eBV first, then automatically continues in standard mode when real-time processing is ineligible, unavailable, incomplete, or unsuccessful. | Latency-sensitive requests that should retain the broader standard process as a fallback. | | `realtime_only` | Attempts only real-time eBV. The request fails if real-time processing cannot complete; standard processing never starts. | Workflows that require a bounded real-time outcome and can handle a terminal failure without fallback. | ## 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: ```json theme={null} { "data": { "id": "bv_...", "status": "pending", "current_processing_mode": "realtime" } } ``` 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.