How to Get Your The Trade Desk API Key

May 29, 2026

There is no self-serve path to a The Trade Desk API key. This is the most important thing to know before reading further: unlike Meta, Google Ads, TikTok, or any of the other ad platforms where any developer can register an app and request access, The Trade Desk's API is closed partner infrastructure. You can't sign up for it. There's no public developer portal you can register on without an existing commercial relationship. API access is provisioned by your TTD account team, often with additional contractual terms and fees on top of your platform spend.

That's not a gotcha — it's the actual access model in 2026. The Trade Desk is an enterprise Demand-Side Platform (DSP) serving agencies, adtech vendors, and large advertisers with significant programmatic media buying spend. The API is a value-add for that ICP, not a developer surface aimed at the broader B2B SaaS ecosystem.

This guide covers what API access actually requires, what the authentication model looks like, what's available once you're in, and the practical alternatives if you don't have a direct TTD relationship.

Key takeaways

• No self-serve API access. You need an existing The Trade Desk seat or partnership, explicit API enablement by your account team, and API-specific credentials. There is no public developer signup.
• API enablement may carry additional fees. Practitioner reports describe one-time enablement fees plus recurring monthly API costs on top of platform spend — typical for enterprise API access models.
• TTD does not use OAuth 2.0 like other ad platforms. Authentication uses TTD-managed API accounts with username/password and long-lived API tokens — closer to a service-account model than a modern OAuth client.
• The canonical base URL is https://api.thetradedesk.com/v3/... for Platform API endpoints. Conversions endpoints sit on the insight.adsrvr.org domain. Reporting (My Reports) and Data Integration APIs are separate suites under the same Partner infrastructure.
• The hierarchy is Partner / Seat → Advertiser → Campaign → Ad Group → Ad, with PartnerId, AdvertiserId, plus advertiser-level secret keys for specific first-party data and conversions flows.
• The Kokai rebrand is a UI and product-experience evolution. It is not a new API surface — the underlying Platform APIs continue under the same authentication patterns and base URLs.
• For teams without a TTD relationship, the practical paths are: (1) work through an agency or partner that already has TTD API access, (2) use an integration partner with existing commercial and technical access in place, or (3) become a TTD customer or partner.

Before you start

You'll need:

• An active The Trade Desk seat or partner relationship — as a customer, agency, or approved adtech partner
• A TTD account representative who can submit your API enablement request
• Willingness to sign additional API-specific contractual terms if required
• Budget for any API enablement fees that may apply on top of platform spend
• Clarity on which API suite you need: Platform API (campaign management), Data Integration API (first-party data activation), My Reports (reporting), or Conversions endpoints

If none of those apply, the realistic path is through a partner that already has the commercial and technical integration. Generic B2B SaaS engineers without an existing TTD relationship will not get API access by applying directly.

Step-by-step: getting The Trade Desk API access in 2026

1. Confirm eligibility

Before contacting anyone, confirm you're in the eligible category: an existing TTD customer with a seat, an agency operating on behalf of advertisers with seats, an approved adtech partner, or a tool provider with a documented integration path. If you're none of these, this is the step where the process stops for most readers.

2. Request API access from your account team

Contact your TTD account representative directly. State clearly:

• Your existing partner or advertiser relationship and Partner ID
• The specific use case (campaign management, reporting, first-party data activation, conversions tracking)
• Which API suite you need (Platform, Data Integration, My Reports, etc.)
• Expected volume and which advertisers' data you'll work with
• Whether you need sandbox access for development before going to production

API enablement is a partner-level decision at TTD, not a self-serve toggle. Approval timelines depend on use case complexity and your existing relationship strength.

3. Sign required API terms

API access typically requires signing platform and API-specific contractual terms beyond your standard TTD platform agreement. Practitioner reports describe both one-time and recurring fees for API enablement, which vary by use case and partner tier.

4. Receive API credentials

Once enabled, TTD's account team provisions credentials, typically through a secure channel. You'll receive:

• API username and password for a dedicated API user account (separate from your personal UI login)
• A Partner ID that scopes API access to your partner-level configuration
• For first-party data and conversions integrations: Advertiser IDs and Advertiser Secret Keys at the advertiser level — accessible in the UI under Advertiser → Preferences → First Party Data Credentials / Seat Identifiers & Keys

Some integrations use long-lived API tokens issued through TTD's Authentication endpoint instead of (or in addition to) username/password authentication.

5. Choose sandbox or production

TTD provides separate sandbox and production environments. The same credentials typically work against both — environment selection is controlled by base URL rather than separate user accounts:

• Production: https://api.thetradedesk.com/v3/...
• Sandbox: provided in your onboarding documentation, behind the Partner Portal

Sandbox is for testing integrations without affecting real campaigns or spend. Use it during development and validate against production only with explicit account-team coordination.

6. Authenticate and make API calls

The authentication pattern is:

1. POST your API username and password to TTD's authentication endpoint (documented inside the Partner Portal) to obtain a long-lived API token
2. Include the token in subsequent API requests in the appropriate header
3. Use the Partner ID and relevant Advertiser IDs to scope your requests to the entities you have access to

The exact auth endpoint, token format, and TTL are documented inside the Partner Portal — they're not publicly accessible. Most third-party integration tools abstract this behind a simple "username + password + Partner ID" configuration flow.

The gotcha: TTD's access model has its own quirks

This is not OAuth, and that matters architecturally. Engineers building integrations who expect Google Ads / DV360-style service accounts, or Meta-style OAuth with short-lived access tokens and refresh tokens, will need to adjust their assumptions. TTD's model is a credentialed API user with a long-lived token — closer to a service account with a durable API key than a public OAuth client. Build your integration around that reality.

Multi-tenant access is centrally controlled, not OAuth-distributed. Agencies managing many advertisers can scope API access across their entire partner configuration, but the multi-tenant pattern is set up through TTD's partner configuration — not through individual users granting OAuth consent like Meta Business Manager or TikTok Business Center. One API user, scoped at the partner level, can access many advertisers underneath that partner.

Kokai is UI, not a new API. The Trade Desk rebranded its platform experience to Kokai (after the earlier Solimar revamp), positioning it as the AI-driven DSP experience. Despite the strong product narrative around Kokai, there is no separate "Kokai API" — underlying Platform APIs continue under the same authentication patterns and base URLs documented in the Partner Portal. The rebrand is a product layer on top of the same API surface.

Different API suites, different credentials, sometimes different endpoints. The Platform API (campaign management), Data Integration API (audience uploads), My Reports (reporting), and Conversions endpoints are different products under the same Partner infrastructure. Some require different access provisioning (e.g., "third-party API access to My Reports" is a separate enablement). Conversions endpoints sit on insight.adsrvr.org, not the main api.thetradedesk.com host. Ask your account team specifically which suites you're enabled for.

Hard delete is rare across the entity tree. TTD's API supports create, update, and status changes (pause, archive, draft) for most campaign objects. Hard deletion is generally not part of the model — campaigns and ad groups are kept for reporting history. Plan for status-based lifecycle management rather than purge-and-recreate workflows.

Rate limits exist but aren't public. Public rate-limit documentation is minimal. Integration tools and agencies that work with TTD treat extraction with appropriate caution — scheduled batch syncs rather than high-frequency polling, conservative request pacing, and back-off on errors. Assume meaningful but undocumented limits and design accordingly.

Security and credential handling

Treat the API token like a service-account credential. Long-lived tokens stored without rotation are operationally simpler than OAuth refresh loops, but they carry concentrated risk. Store in a proper secret manager. Rotate after suspected exposure.

Per-advertiser secret keys are sensitive. Advertiser IDs are not secret on their own — they appear in URLs and reporting exports. But the advertiser secret keys used for first-party data uploads and conversions are credentials that authorize writing data to that advertiser's account. Treat them with the same care as the API token.

Audit user access regularly. TTD-side user permission changes can silently affect what your integration can access. If a customer's TTD partner configuration changes — advertisers added or removed, permissions revoked — your integration's effective access changes too. Build health checks against the access state you expect.

Use sandbox for any non-production workload. Development, testing, demos, internal dashboards that aren't billed customer-facing reporting — all should run against sandbox. Production credentials are for production traffic.

Is there an API-key alternative?

For the Platform API: not really. The authentication model is closer to API-key-style than OAuth, but the credentials still come from TTD provisioning, not a static key you generate yourself. For Conversions API and first-party data flows: the advertiser secret keys function as per-advertiser API keys for those specific endpoints, but they still require an existing commercial relationship to obtain.

Frequently asked questions

Can I get a TTD API key without being a customer? Realistically, no. The API is provisioned through TTD's account team, requires API-specific contractual terms, and may carry enablement fees. If you're a B2B SaaS without an existing TTD relationship, your practical paths are (1) become a TTD customer, (2) work with an agency or partner that has a seat, or (3) use an integration partner with existing commercial and technical access in place.

How does TTD compare to DV360 for API access? Both are programmatic Demand-Side Platforms with similar scope and capabilities. The access model is dramatically different. DV360 uses standard Google OAuth 2.0 — any developer can create a Google Cloud project, enable the API, and start integrating. TTD requires an existing commercial relationship, account-team approval, and TTD-managed credentials. From a technical capability perspective they're peers; from a developer accessibility perspective DV360 is open and TTD is closed.

What's the difference between the Platform API, Data Integration API, My Reports, and Conversions API? Different jobs under the same Partner infrastructure. Platform API handles campaign management (advertisers, campaigns, ad groups, ads). Data Integration API handles first-party audience uploads and customer data onboarding. My Reports provides reporting and analytics. Conversions API handles server-side conversion event tracking via insight.adsrvr.org. Each may have separate enablement requirements — ask your account team which suites you're approved for.

Is the Kokai platform a new API? No. Kokai is The Trade Desk's product narrative around AI-driven media buying — a UI and capabilities layer on top of the existing Platform APIs. There's no separate "Kokai API" with different authentication or endpoints. Integration patterns remain those of the underlying Platform APIs documented in the Partner Portal.

Why doesn't TTD use OAuth 2.0? TTD's API model predates the OAuth 2.0 standardization across ad platforms and reflects its different positioning: a closed, enterprise platform rather than a developer surface. There's no public announcement of a switch to OAuth 2.0 for the Platform API. Plan for the long-lived-token model — it's stable and unlikely to change in the near term.

Where Unified fits

Unified.to is one of the integration partners with existing The Trade Desk commercial and technical access — meaning teams that need TTD data without taking on the partner-onboarding cost themselves can build through Unified rather than negotiating directly with TTD. Unified provides a single API across The Trade Desk, Google Display & Video 360, Google Campaign Manager 360, Amazon Advertising, Meta Ads, LinkedIn Ads, TikTok Ads, Snapchat, Pinterest Ads, Reddit Ads, X Ads (Twitter Ads), Google Ads, Microsoft Advertising, and two other advertising integrations — 15 in total — covering campaigns, ad groups, ads, creatives, targeting, and reporting through a normalized data model.

For The Trade Desk specifically, Unified handles the credentialed API user authentication, long-lived token management, Partner → Advertiser → Campaign → Ad Group → Ad hierarchy navigation, and the Platform API endpoint structure behind a single authorization step. Real TTD objects map to Unified's normalized models: ads_organization (list/get), ads_campaign, ads_group, and ads_creative with create, update, list, and get — mirroring TTD's actual API capability around campaign state management rather than hard deletion. ads_ad has full CRUD, and ads_report and ads_target handle reporting and targeting access. Vendor-specific endpoints — including the Data Integration API for first-party audience activation, the Conversions API on the insight.adsrvr.org host, and the more advanced bidding configurations — are available through pass-through access.

If you're evaluating whether to pursue direct TTD API access or use a unified API, the question is less about TTD's auth complexity in isolation and more about whether the partner-onboarding cost, contractual overhead, and the operational reality of managing yet another ad platform's distinctive credential model is justified by your use case — or whether abstracting it through an integration partner with existing commercial access makes more strategic sense.

→ Start your 30-day free trial

→ Book a demo