specification: API Commons Rate Limits
specificationVersion: '0.1'
schema: https://raw.githubusercontent.com/api-evangelist/interface-research/main/schema/api-commons.yml#/$defs/RateLimits
provider: Google Display & Video 360
providerId: google-display-video-360
created: '2026-05-04'
generated: '2026-08-13'
modified: '2026-08-13'
method: searched
source: https://developers.google.com/display-video/api/limits
docs: https://developers.google.com/display-video/api/limits
supersedes: >-
  The 2026-05-04 bulk-sweep scaffold that previously occupied this file. That version asserted
  X-RateLimit-* response headers, a 10 rpm free tier and a 503 quotaExceeded code — none of which
  Google publishes for this API. Every value below is now read from Google's own limits page.
description: >-
  Published quota limits for the Display & Video 360 API. Google enforces two independent
  dimensions at once — a project-wide budget and a per-advertiser budget — and each is split into
  a total-request limit and a stricter write-request limit. Both are per-minute. Google states
  plainly that increases cannot be requested, which makes these hard ceilings rather than
  negotiable defaults, and failed requests still consume quota.
tags:
  - Campaign Management
  - Display Ads
  - DV360
  - Programmatic Advertising
  - Rate Limiting
  - Quotas
  - Throttling
headers:
  limit: null
  remaining: null
  reset: null
  retryAfter: null
  policy: null
  note: >-
    Google publishes NO rate-limit response headers for this API. There is no X-RateLimit-*,
    no RateLimit-* (RFC 9331 draft), and no documented Retry-After. An agent cannot read its
    remaining budget from a response; the only runtime signal is the 429 itself. Consumption is
    observable out-of-band through the Google Cloud console quota dashboard for the calling
    project. This is a real gap in the API's agent-readiness, not a gap in this measurement.
responseCodes:
  throttled: 429
  quotaExceeded: 429
  rpcStatus: RESOURCE_EXHAUSTED
  message: Resource has been exhausted (e.g., check quota).
limits:
  - name: Project total requests
    scope: per-project
    metric: requests
    limit: 1500
    window: minute
    timeFrame: minute
    burst: null
    tier: all
    applies_to: every method in the API
  - name: Project write requests
    scope: per-project
    metric: write_requests
    limit: 700
    window: minute
    timeFrame: minute
    burst: null
    tier: all
    applies_to: every mutating method (create, patch, delete, bulk*, upload)
  - name: Advertiser total requests
    scope: per-advertiser-per-project
    metric: requests
    limit: 300
    window: minute
    timeFrame: minute
    burst: null
    tier: all
    applies_to: >-
      any method carrying an advertiser ID in the URL path — the entire /v4/advertisers/{advertiserId}/…
      tree. Counts against this limit IN ADDITION to the project-wide limit.
  - name: Advertiser write requests
    scope: per-advertiser-per-project
    metric: write_requests
    limit: 150
    window: minute
    timeFrame: minute
    burst: null
    tier: all
    applies_to: mutating methods with an advertiser ID in the path
weighted_methods:
  note: These methods consume 5x write quota per call.
  multiplier: 5
  methods:
    - customBiddingAlgorithms.scripts.create
    - customBiddingAlgorithms.uploadScript
    - firstPartyAndPartnerAudiences.create
    - firstPartyAndPartnerAudiences.editCustomerMatchMembers
    - media.upload
policy:
  increases_available: false
  increase_note: Google states that increases cannot be requested for Display & Video 360 API quota limits.
  failed_requests_consume_quota: true
  remediation: >-
    Examine usage patterns and slow the request rate. Google's guidance is workflow redesign
    (batching, bulk methods, fewer polling loops) rather than a quota increase, because no
    increase path exists.
limit_count: 4