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

# Rate Limits

> Understand how Develop Health API limits are scoped, measured, and communicated.

Develop Health applies rate limits per organization. All credentials for the same organization share the organization's allowances.

Limits protect API availability and keep accepted prior authorization and benefit verification work within recoverable processing capacity. The limits assigned to your organization may vary based on your integration and contracted workload.

## Applicable policies

Limits are applied as follows:

| Policy                  | Applies to                                                                                          | Quota measurement                                              |
| ----------------------- | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| `read-endpoint-minute`  | Each GET endpoint, counted independently                                                            | Requests per minute                                            |
| `write-endpoint-minute` | Each POST, PATCH, and DELETE endpoint, counted independently                                        | Requests per minute                                            |
| `rtbv-drug-minute`      | Benefit verification creation with `preferred_processing_mode` set to `realtime` or `realtime_only` | One quota unit per submitted drug, measured per minute         |
| `bv-drug-24h`           | Benefit verification creation in any processing mode                                                | One quota unit per submitted drug, measured per 24-hour window |
| `pa-create-24h`         | Prior authorization creation                                                                        | Prior authorizations per 24-hour window                        |

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 both `rtbv-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.

| Header             | Description                                                              |
| ------------------ | ------------------------------------------------------------------------ |
| `RateLimit-Policy` | The applicable policy limits and windows                                 |
| `RateLimit`        | The remaining quota and effective window for each reported policy        |
| `Retry-After`      | The minimum number of seconds to wait before retrying a rejected request |

The fields use these parameters:

| Parameter | Meaning                                   |
| --------- | ----------------------------------------- |
| `q`       | Quota allocated by the policy             |
| `w`       | Policy window in seconds                  |
| `r`       | Quota units currently remaining           |
| `t`       | Effective window in seconds               |
| `dh-unit` | Develop Health quota unit, such as `drug` |

This example shows the headers for a benefit verification request with `preferred_processing_mode: "realtime"`. The quota values are illustrative:

```http theme={null}
RateLimit-Policy: "write-endpoint-minute";q=120;w=60, "rtbv-drug-minute";q=20;w=60;dh-unit="drug", "bv-drug-24h";q=5000;w=86400;dh-unit="drug"
RateLimit: "write-endpoint-minute";r=84;t=42, "rtbv-drug-minute";r=12;t=42, "bv-drug-24h";r=2180;t=72000
```

## Rate-limit responses

When a request exceeds any applicable policy, the API returns `429 Too Many Requests`. The response includes `Retry-After`, expressed in seconds, and identifies the policies currently preventing the request from being accepted.

```http theme={null}
HTTP/1.1 429 Too Many Requests
Retry-After: 42
RateLimit-Policy: "rtbv-drug-minute";q=20;w=60;dh-unit="drug"
RateLimit: "rtbv-drug-minute";r=0;t=42
```

Wait for at least the duration specified by `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.