How to Get Your Google Display & Video 360 API Key
May 29, 2026
There is no "DV360 API key." Display & Video 360 supports OAuth 2.0 only — no API keys, no basic auth, no static tokens. For backend SaaS integrations the recommended pattern is service-account authentication. For multi-tenant SaaS where customers connect their own DV360 accounts, three-legged user OAuth is the standard.
What makes DV360 auth distinctive — and easier to set up than Campaign Manager 360, despite the shared Google Marketing Platform lineage — is that there is no userProfileId, no Google-account-team enablement step, and no developer-token review process. Access is determined directly by DV360 user roles assigned in the DV360 UI. The rest is standard Google Cloud OAuth.
This guide covers the 2026 process: enabling the Display & Video 360 API in Google Cloud, creating credentials (service account or user OAuth), getting your authenticating identity added as a DV360 user with the right role, and the access-scoping model that determines what your integration can touch.
Key takeaways
- DV360 uses OAuth 2.0 only. Backend integrations should use service accounts; multi-tenant SaaS connecting customer accounts should use three-legged user OAuth.
- The API name in Google Cloud Console is "Display & Video 360 API". Current version is v4 as of 2026.
- Three OAuth scopes serve different purposes:
display-video(main API),display-video-user-management(service-account-only, for theusers.*endpoints), anddoubleclickbidmanager(DBM legacy, only for the separate allowlisted Exchange Reporting API). - No
userProfileIdequivalent. Access is determined implicitly by the authenticated principal's DV360 user roles on specific partners and advertisers. - No account-team enablement step. If your organization has DV360, an Admin can grant your identity a role and you can start calling the API.
- The DV360 hierarchy is partner → advertiser → campaign → insertion order → line item. DV360 user roles are scoped within this tree.
- Hard rate limits: 1500 requests/minute per project, 700 writes/minute per project, 300/min/advertiser, 150 writes/min/advertiser. No quota-increase process — design for these limits.
Before you start
You'll need:
- A Google Cloud project with billing enabled
- A DV360 account with Admin access (or a colleague who can assign roles)
- An understanding of which DV360 partners and advertisers your integration needs to reach — DV360 user roles are scoped to specific partners and advertisers, not granted globally
- For backend integrations: a server capable of signing JWTs and securely storing service-account JSON keys
DV360's three API-eligible user roles are Admin, Standard, and Read only. Other DV360 roles exist but do not have API access — confirming the role level before configuring credentials saves debugging time later.
Step-by-step: creating DV360 API credentials in 2026
1. Enable the Display & Video 360 API in Google Cloud
Go to console.cloud.google.com and create or select a project. From the left navigation: APIs & Services → Library. Search for Display & Video 360 API and click Enable.
If your integration also needs Exchange Reporting (a separate, allowlisted API), you'll need to apply for that separately — it lives under the Private section of the API Library after Google has allowlisted your project.
2. Choose your credential type
For backend integrations, create a service account. For multi-tenant SaaS where each customer connects their own DV360 account, create an OAuth client ID for user-flow authentication.
For a service account: in APIs & Services → Credentials, click Create credentials → Service account. Give it a descriptive name. Once created, click into the service account, go to Keys → Add key → Create new key → JSON. Download and store the key securely.
For user OAuth: configure the OAuth consent screen first (app name, support email, scopes, test users), then create an OAuth client ID under Credentials with the appropriate application type (web, desktop) and redirect URIs.
3. Add your authenticating identity as a DV360 user
This is the step that gates everything else. In the DV360 UI, an Admin must:
- Take the email of your service account (e.g.,
dv360-svc@your-project.iam.gserviceaccount.com) or the user account being authorized - Add it as a DV360 user
- Assign Admin, Standard, or Read only role on the specific partners and advertisers the integration needs to reach
DV360 has no global API access — every API call resolves against the authenticated identity's roles on specific entities. If your identity has a Standard role on Partner A but no role on Partner B, calls referencing Partner B's advertisers will return PERMISSION_DENIED.
For multi-tenant SaaS, this step is what each customer does in their own DV360 account during onboarding. For internal/single-tenant integrations, it's a one-time setup.
4. Request the right OAuth scopes
The three scopes serve specific purposes:
https://www.googleapis.com/auth/display-video— main API access (campaigns, line items, creatives, targeting, reports). Required for almost every call.https://www.googleapis.com/auth/display-video-user-management— required only for theusers.*endpoints (managing DV360 users programmatically). Service-account flow only; not available for three-legged user OAuth.https://www.googleapis.com/auth/doubleclickbidmanager— only for the separate allowlisted DV360 Exchange Reporting API. Not needed for the main DV360 API.
Request only the scopes you need. Most integrations only need display-video.
5. Make authenticated API calls
Every request goes to https://displayvideo.googleapis.com/v4/... with Authorization: Bearer {access_token} in the header. Examples:
GET https://displayvideo.googleapis.com/v4/partners/{partnerId}
GET https://displayvideo.googleapis.com/v4/advertisers/{advertiserId}/campaigns
GET https://displayvideo.googleapis.com/v4/advertisers/{advertiserId}/insertionOrders
Note that paths use partners/{partnerId} and advertisers/{advertiserId} directly, not userprofiles/{profileId}/... like CM360. This is the structural simplification: DV360 doesn't have a profile abstraction layer.
Google's official client libraries (Python, Node.js, Java, Go, .NET, PHP, Ruby) wrap JWT signing and token refresh — using them is significantly less error-prone than building the flow by hand.
OAuth user flow vs. service account: when to use each
Service accounts are the right pattern for backend integrations where your application acts as a system user:
- ✅ Stable server-side credentials — no interactive re-auth for scheduled jobs
- ✅ Required for the
users.*endpoints (service-account-only scope) - ✅ One technical identity that can be granted per-customer DV360 user roles
- ❌ JSON keys are sensitive credentials needing rotation and secret-manager storage
- ❌ Each customer must manually add the service-account email as a DV360 user
Three-legged user OAuth is the right pattern for multi-tenant SaaS where customers connect their own DV360 accounts:
- ✅ Each customer authorizes through Google's consent screen — no per-customer Admin work needed
- ✅ Users can revoke per-app access without affecting their DV360 account
- ✅ Permissions naturally inherit from the authorizing user's DV360 role
- ❌ Refresh-token management is the integrator's responsibility
- ❌ Tokens are tied to individual users — if the user leaves, the integration breaks
For most B2B SaaS connecting customer DV360 accounts, three-legged user OAuth is the cleaner pattern. The DV360 user role of the person authorizing becomes the effective access ceiling for the integration.
The gotcha: DV360's auth model has its own quirks
Don't confuse DV360 with Campaign Manager 360. DV360 (programmatic media buying) and CM360 (ad serving and measurement) are separate products with separate APIs, scopes, and access models. They share Google Marketing Platform lineage but the endpoints and patterns differ — DV360 has no userProfileId, and CM360 has no insertion-order or line-item hierarchy. People searching "DV360 API key" sometimes mean CM360 and vice versa. Make sure you're reading docs for the right product.
The three API-eligible roles are the only roles that work. DV360 has multiple user roles, but only Admin, Standard, and Read only grant API access. Other roles (creative-only, reporting-only, etc.) will produce 403 errors even though the user can log into DV360 UI and see data.
Service account not added as a DV360 user. This is the #1 cause of 403 errors. You'll see PERMISSION_DENIED with "No permission for attempted operation on partner with id X." The service account exists in Cloud, has a valid token, and the API is enabled — but it was never added as a DV360 user. The fix: have an Admin add the service account email in DV360 with the right role.
Cross-customer ID confusion. Partner IDs and advertiser IDs are stable but only meaningful within the access tree of the authenticating identity. Mixing Google Ads customer IDs or CM360 advertiser IDs with DV360 IDs produces 404 NOT_FOUND or 403 PERMISSION_DENIED errors that look like access problems but are actually wrong-ID problems.
Rate limits are absolute. 1500 total requests/minute per project, 700 writes/minute, 300 requests/minute/advertiser, 150 writes/minute/advertiser. Some methods are "write-intensive" and count as 5 write requests each. There is no quota-increase process — design traffic patterns that stay under the limits from day one.
Security and credential handling
Store service-account JSON keys in a proper secret manager. AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or equivalent. Never commit them to repositories. Rotate keys periodically — the rotation process is straightforward but only works if you've planned for it.
Refresh proactively. Access tokens expire after one hour. Refresh at the 55-minute mark with retry logic and exponential backoff.
Audit DV360 user access regularly. Run a periodic check that your service-account identity's roles match what the integration needs. Stale roles (granted for a deprecated workflow, never revoked) widen the blast radius if credentials are ever compromised.
Use least-privilege scopes. Most integrations only need display-video. Don't request display-video-user-management unless you actually call the user-management endpoints. Don't request doubleclickbidmanager unless you're allowlisted for Exchange Reporting.
Is there an API-key alternative?
No. DV360 does not support API keys, basic authentication, or standalone bearer tokens. OAuth 2.0 is the only authentication mechanism — either service-account flow or three-legged user OAuth. Every architecture decision in your integration — token storage, refresh scheduling, identity management, customer onboarding — flows from that constraint.
Frequently asked questions
Why doesn't DV360 use userProfileId like CM360? Different product, different access model. CM360 inherited the userProfileId mechanic from DoubleClick Campaign Manager's user-profile abstraction. DV360 was designed without that layer — access is determined directly by DV360 user roles on partners and advertisers, with no intermediate profile object.
What happened to the Bid Manager (DBM) API? DBM v1.1 was fully sunset in April 2023. The Bid Manager v2 brand was effectively superseded by the Display & Video 360 API for campaign management. The only DBM-lineage piece that remains in 2026 is the separate, allowlisted DV360 Exchange Reporting API, which still uses the doubleclickbidmanager scope. For net-new work targeting campaign management, planning, trafficking, or reporting (other than Exchange Reporting), use the Display & Video 360 API.
Do I need to get on an allowlist or wait for partner approval? Not for the main Display & Video 360 API. If your organization has DV360 access, an Admin can grant your identity a role and you can call the API. The only allowlist requirement is the separate Exchange Reporting API.
Why am I getting 403 errors even though my token is valid? Almost always one of three things: (1) the authenticated identity hasn't been added as a DV360 user at all, (2) it has a role that doesn't grant API access (i.e., not Admin/Standard/Read-only), or (3) it doesn't have a role on the specific partner or advertiser in the request path.
How does this compare to CM360 or Google Ads auth? Simpler than both. CM360 requires Google account team enablement at the CM360 account level plus userProfileId discovery. Google Ads requires developer-token review and tiered production access. DV360 has neither — just enable the API, create credentials, and have an Admin grant the right DV360 role.
Where Unified fits
Unified.to provides a single API across Google Display & Video 360, Google Campaign Manager 360, Google Ads, Meta Ads, LinkedIn Ads, TikTok Ads, Microsoft Advertising, Amazon Advertising, and 7 other advertising integrations — 15 in total — covering campaigns, ad groups, ads, creatives, insertion orders, targeting, and reporting through a normalized data model.
For DV360 specifically, Unified handles OAuth credentials and refresh, scope routing, partner/advertiser access scoping, and the v4 endpoint structure behind a single authorization step. Real DV360 objects map to Unified's normalized models: ads_organization (list/get), ads_campaign, ads_creative, ads_insertionorder, ads_group, and ads_ad with full CRUD, plus ads_report and ads_target for reporting and targeting access. The insertion-order and targeting objects are DV360-specific — they aren't in the CM360 integration because CM360 doesn't have insertion orders or programmatic targeting in the same way. Vendor-specific endpoints, including Exchange Reporting and the more advanced bidding strategy configurations, are available through pass-through access.
If you're evaluating whether to build DV360 integration directly or use a unified API, the question is whether the ongoing maintenance — credential rotation, role auditing, rate-limit management, version migrations — is something your team should own, or something to abstract behind a single connection.