Applicable policies
Limits are applied as follows:
Each request counts toward every applicable policy. A request is accepted only when it fits within all applicable limits, so the most restrictive current limit governs.
Endpoint policies are partitioned by HTTP method and normalized route. For example, requests to
GET /prior-authorization/{id} share one organization-level allowance regardless of the prior authorization ID. Traffic to another GET endpoint uses a different allowance.
Cancellation and other control operations use their endpoint policy. They do not consume benefit verification drug or prior authorization creation quotas.
Requests containing multiple drugs
Every benefit verification drug policy uses the same quota unit: one submitted drug equals one quota unit. This applies to bothrtbv-drug-minute and bv-drug-24h.
A request containing three drugs requires three available quota units in every applicable benefit verification drug policy.
Develop Health accepts or rejects the complete request. A rate-limited request does not create a partial set of benefit verifications or consume drug quota.
Response headers
API responses include the policies applicable to the request and their current availability.
The fields use these parameters:
This example shows the headers for a benefit verification request with
preferred_processing_mode: "realtime". The quota values are illustrative:
Rate-limit responses
When a request exceeds any applicable policy, the API returns429 Too Many Requests. The response includes Retry-After, expressed in seconds, and identifies the policies currently preventing the request from being accepted.
Retry-After before retrying. When both Retry-After and a RateLimit effective window are present, follow Retry-After. Add a small amount of random jitter when scheduling concurrent retries.
A request rejected with 429 does not create partial work. Retrying the complete request after the indicated delay is safe.