# Quota

The [Display \& Video 360 API quota](https://developers.google.com/display-video/api/limits) limits the rate in which a project can make
requests to the API.

Follow these best practices to better use your Display \& Video 360 API quota.

## Make requests across advertisers at the same time

Display \& Video 360 API quota is set per project and per advertiser. Project quota limits
the requests made by a project. Advertiser quota limits the requests made by a
project to an advertiser.

To use all of your project quota, make requests across advertisers at the same
time.

## Use `list` query parameters

Use `list` method query parameters to only include wanted resources. Fewer
resources need fewer requests to list.

`list` methods offer three key parameters:

- **`pageSize`** sets the number of resources that can be returned by the request. Default page size depends on the method. Set this to the highest value to list more resources per request.
- **`filter`** limits the listed resources by the provided criteria. Set this to list only a subset of resources. See [Filter list requests](https://developers.google.com/display-video/api/guides/concepts/optimization/filter-lists) for more information.
- **`orderBy`** orders the listed resources by the given property. Set this to retrieve the ceiling or floor of the resource list with fewer requests.

## Use bulk and resource-wide functions

Bulk and resource-wide functions perform complex tasks. A single request to
these methods can take the place of multiple requests to others.

For more information about these methods, see [Bulk Requests](https://developers.google.com/display-video/api/guides/concepts/optimization/bulk-requests).

## Cache IDs

Many Display \& Video 360 API actions require IDs retrieved using the API. Examples include
[targeting option IDs](https://developers.google.com/display-video/api/reference/rest/current/targetingTypes.targetingOptions#TargetingOption.FIELDS.targeting_option_id) and [Google audience IDs](https://developers.google.com/display-video/api/reference/rest/current/googleAudiences#GoogleAudience.FIELDS.google_audience_id). Store
IDs locally so that you don't need to keep retrieving them.

Using IDs for resources that are deprecated or deleted can return an error. You
should retrieve cached IDs weekly to confirm their status.

## Use exponential backoff

Exponential backoff is an error-handling strategy. It retries requests over an
increasing amount of time.

While polling a long-running task, such as an [SDF download
task](https://developers.google.com/display-video/api/reference/rest/current/sdfdownloadtasks.operations), an exponential backoff strategy can reduce the
number of requests sent.

Our [SDF download code examples](https://developers.google.com/display-video/api/guides/tasks/download-sdf/poll-task) use exponential backoff with
our client libraries. The following is an example of exponential backoff flow:

- Retrieve the `Operation` object with the [`get`](https://developers.google.com/display-video/api/reference/rest/current/sdfdownloadtasks.operations/get) request.
  - If [`done`](https://developers.google.com/display-video/api/reference/rest/current/sdfdownloadtasks.operations#Operation.FIELDS.done) is not true, the task is still running.
  - Wait 5 seconds + a random number of seconds, then retry the request.
- Retrieve the operation.
  - If `done` is not true, the task is still running.
  - Wait 10 seconds + a random number of seconds, then retry the request.
- Retrieve the operation.
  - If `done` is not true, the task is still running.
  - Wait 20 seconds + a random number of seconds, then retry the request.
- Retrieve the operation.
  - If `done` is not true, the task is still running.
  - Wait 40 seconds + a random number of seconds, then retry the request.
- Retrieve the operation.
  - If `done` is not true, the task is still running.
  - Wait 80 seconds + a random number of seconds, then retry the request.
- **Continue this pattern until `done` is true or a maximum time elapsed is
  reached.**