How to Get Your Google Campaign Manager 360 API Key
May 29, 2026
There is no single "Campaign Manager 360 API key." CM360 uses OAuth 2.0, and for most SaaS integrations the recommended path is service-account authentication rather than user-OAuth — the opposite of how Google Ads works. This is the most important architectural fact about CM360 auth, and it shapes everything else: credential setup, multi-tenant patterns, error modes, and onboarding flow.
This guide covers the 2026 process for getting CM360 API access: enabling the API in Google Cloud, creating service-account credentials, getting your CM360 account configured for API access (which requires Google's account team), and the userProfileId mechanic that scopes every API call.
Key takeaways
- CM360 requires OAuth 2.0 — there are no API keys, basic auth, or standalone tokens. For multi-tenant SaaS, service accounts are the recommended pattern.
- The API name in Google Cloud Console is "Campaign Manager 360 API" (formerly DoubleClick Campaign Manager / DCM — the legacy "DFA" naming persists in scopes and endpoints).
- Unlike Google Ads, CM360 has no developer-token review or production-access tier. But API access must still be enabled at the CM360 account level by Google's account team.
- Every CM360 API call requires a
userProfileIdin the URL path. The service-account identity must be added as a CM360 user in each customer's account to obtain a profile. - v4 is the only supported version as of 2026. v3.5 has been sunset.
- Three legacy DFA scopes carry different permissions:
dfareporting(reports),dfatrafficking(campaign management),ddmconversions(offline conversions).
Before you start
You'll need:
- A Google Cloud project with billing enabled
- Admin access to a CM360 account with API access enabled by Google's account team (request this through your Google Marketing Platform representative)
- For multi-tenant SaaS: a server backend capable of signing JWTs and securely storing service-account JSON keys
- For internal/single-tenant use: a CM360 user account with the permissions you'll need on the API side
If you don't already have a relationship with a Google Marketing Platform rep, this step is the first real bottleneck. CM360 isn't self-serve at the account level — Google's team has to enable API access on your CM360 account before any of the Cloud-side setup matters.
Step-by-step: creating CM360 API credentials in 2026
1. Enable the Campaign Manager 360 API in Google Cloud
Go to console.cloud.google.com and create or select the project you'll use for the integration. From the left navigation, select APIs & Services → Library. Search for Campaign Manager 360 API and click Enable.
This is per-project. If you maintain separate environments (development, staging, production), enable the API in each.
2. Choose your credential type
For most SaaS integrations, you'll create a service account. For internal tools where a user logs in interactively, you'll create an OAuth client ID. The two patterns serve different needs and have different multi-tenant implications — covered in the next section.
For a service account: in APIs & Services → Credentials, click Create credentials → Service account. Give it a name, grant it the roles it needs in your project, and skip the user-access step. Once created, click into the service account, go to Keys, and create a new JSON key. Download and store this securely — it's what your backend will use to sign JWTs and obtain access tokens.
For an OAuth client ID: configure the OAuth consent screen first (app name, scopes, test users), then create an OAuth client ID under Credentials with the appropriate application type (web, desktop, installed app) and redirect URIs.
3. Add your service-account identity as a CM360 user
This is the CM360-specific step that has no equivalent in Google Ads.
For each customer account you'll access, an admin on the customer's CM360 account must:
- Take the service-account email (e.g.,
cm360-svc@your-project.iam.gserviceaccount.com) - Create a new CM360 user profile using that email as the identity
- Assign appropriate roles and permissions (trafficking, reporting, conversions — match to what your integration needs)
The resulting CM360 user profile has its own userProfileId, which you'll need to discover via userProfiles.list (covered below) and include in every subsequent API call.
This pattern — one service-account identity, separate CM360 user profiles per customer account — is what Google's CM360 documentation explicitly recommends for multi-tenant SaaS integrations.
4. Discover the userProfileId
Once your service account is added as a CM360 user, call userProfiles.list to enumerate the profile IDs available to that identity:
GET https://dfareporting.googleapis.com/dfareporting/v4/userprofiles
Authorization: Bearer {access_token}
This is the only CM360 endpoint that doesn't require a userProfileId in the path. Every other endpoint does. Store the returned profile IDs and use them to scope subsequent API calls — for example:
GET https://dfareporting.googleapis.com/dfareporting/v4/userprofiles/{userProfileId}/campaigns
5. Request the right OAuth scopes
CM360 splits permissions across three scopes:
https://www.googleapis.com/auth/dfareporting— read access for reports and many GET operationshttps://www.googleapis.com/auth/dfatrafficking— trafficking and campaign management (required foruserProfiles.list, campaigns, placements, creatives, ads)https://www.googleapis.com/auth/ddmconversions— offline conversions (Floodlight uploads)
Request only the scopes you need. The service account's CM360 user must have matching permissions in CM360 itself — having a scope in the token without the matching CM360 role still produces 403 errors.
6. Make authenticated API calls
With the service-account JSON, sign a JWT and exchange it at Google's OAuth 2.0 token endpoint for an access token. Include the token in the Authorization: Bearer header on every API request. Access tokens expire after one hour — your backend should refresh proactively, ideally at the 55-minute mark.
Google's official client libraries for Python, Node.js, Java, Go, .NET, PHP, and Ruby wrap the JWT-signing and token-exchange flow — 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 recommended pattern for multi-tenant SaaS integrations. The trade-offs:
- ✅ Stable, server-side credentials — no interactive re-auth for scheduled jobs
- ✅ One technical identity across many customer accounts
- ✅ No dependency on user refresh tokens that can expire or be revoked
- ❌ Each customer must manually add the service-account email as a CM360 user — onboarding friction
- ❌ JSON keys are sensitive credentials that need rotation and secret-manager storage
User OAuth fits better for internal tools or single-tenant integrations:
- ✅ Aligns naturally with user-level permissions ("you see what you can see")
- ✅ Users can revoke per-app consent without affecting their CM360 account
- ❌ Tokens are tied to individual users; if the user leaves or revokes, the integration breaks
- ❌ Harder to operate unattended at scale across many accounts
For B2B SaaS building CM360 integrations, the recommendation is clear: use service accounts, accept the per-customer onboarding step, and store keys in a proper secret manager.
The gotcha: CM360 has its own quirks
Several patterns trip up developers who've worked with other Google APIs:
Don't confuse CM360 with DV360. Campaign Manager 360 (ad serving and measurement) and Display & Video 360 (programmatic media buying) are separate products with separate APIs. They share the Google Marketing Platform umbrella and historical DoubleClick lineage, but the endpoints, scopes, and capabilities are different. Searching "DV360 API" or "Campaign Manager API" returns mixed results — make sure you're reading docs for the right product.
The "DFA" legacy naming is everywhere. Endpoint hostname (dfareporting.googleapis.com), scopes (dfatrafficking, dfareporting), error codes — they all use the DoubleClick For Advertisers naming from the pre-Google-rebranding era. This isn't going to change. Don't waste time looking for the "modern" version.
The userProfileId is path-based, not header-based. Unlike Google Ads' login-customer-id header or Amazon's Amazon-Advertising-API-Scope header, CM360's profile scoping happens in the URL path. Forgetting it doesn't produce a missing-header error — it produces a 404 on a path that looks structurally valid.
Google has to manually enable API access on the CM360 account itself. API access isn't self-serve at the CM360 level — your customer needs to request it through their Google account team. If Cloud Console looks set up but API calls fail with permission errors, this is usually why.
Reports are asynchronous jobs. Reports aren't synchronous API responses — you define a report, run it as a job via reports.run, poll status, then download the resulting file via files.get. Build for chunked downloads, exponential backoff on polling, and the 30-day data backfill window where recent metrics can shift after initial publication.
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 (create a new key, switch production to it, revoke the old one) 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 on failures.
Log refresh outcomes. Track every refresh attempt with timestamp, success or failure, error codes. Repeated failures usually mean a revoked key or a misconfigured service account, not a transient network issue.
Audit which CM360 accounts your service identity has access to. Periodically run userProfiles.list and reconcile against your customer database. Stale profiles (customers who churned, accounts that consolidated) can mask security risks and clutter operational logging.
Is there an API-key alternative?
No. CM360 does not support API keys, basic authentication, or standalone bearer tokens. OAuth 2.0 is the only path — either user-OAuth or service-account flow. For multi-tenant SaaS, service accounts are the recommended pattern, and there is no shortcut around the per-customer CM360-user-creation step.
Frequently asked questions
Why doesn't CM360 require a developer-token review like Google Ads? Different product, different governance model. Google Ads gates production API access via a developer-token tier system because the API can directly affect billed advertising spend at scale. CM360's gatekeeping happens at the CM360 account level (Google's account team enables API access) and at the user-profile level (admins explicitly grant permissions). The result is less paperwork than Google Ads but a slower per-customer onboarding step.
Can I use one service account to access many customers' CM360 accounts? Yes — this is the recommended pattern. One service-account email gets added as a CM360 user in each customer's account, with permissions scoped per account. Your backend stores the mapping of customer → CM360 account → userProfileId and uses the right profile ID on each call.
Why is my service account getting 403 errors even though the token is valid? Almost always one of three things: (1) the service-account email hasn't been added as a CM360 user in the target account, (2) the userProfileId in the path doesn't match the service account's identity, or (3) the OAuth scope doesn't match the endpoint (e.g., calling trafficking endpoints with only the dfareporting scope).
What's the difference between CM360 and DV360 APIs? Different products. CM360 is for ad serving, measurement, and trafficking. DV360 is for programmatic media buying. The APIs, scopes, and capabilities are distinct. Some customers use both; the integrations are separate.
How do I handle the CM360 30-day data backfill window? CM360 continues to update reported data for up to 30 days after the event. For warehouse ingestion, treat the recent 30 days as a "soft" window subject to change, and consider locking historical periods only after the backfill window closes. Communicate this lag to downstream consumers who expect immutable numbers.
Where Unified fits
Unified.to provides a single API across Google Campaign Manager 360, Google Ads, Meta Ads, LinkedIn Ads, TikTok Ads, Microsoft Advertising, Amazon Advertising, and 8 other advertising integrations — 15 in total — covering campaigns, ad groups, ads, creatives, and reporting through a normalized data model.
For Campaign Manager 360 specifically, Unified handles the service-account flow, the per-customer user-profile creation step, the userProfileId discovery and scoping, the three-scope permission model, and the v4 endpoint routing behind a single authorization step. Real CM360 objects map to Unified's normalized models: ads_organization (list/get), ads_campaign, ads_group, ads_ad, and ads_creative with full CRUD, and ads_report for reporting access. Vendor-specific endpoints — including the asynchronous report-job lifecycle, offline conversion uploads, and Floodlight management — are available through pass-through access.
If you're evaluating whether to build CM360 integration directly or use a unified API, the question to ask is whether the per-customer service-account onboarding workflow, the Google-account-team coordination, and the ongoing maintenance of an integration with persistent DCM-era quirks is something your team should own — or something to abstract away.