X Ads API Access: A Second Approval Most Developers Miss (2026)
A working X API developer account gets you posts, users, DMs and Spaces. It does not get you the Ads API. Campaign management, analytics, creatives and custom audiences all sit behind a separate, manually-reviewed request — on a different authentication system than the rest of the platform.
One company, two API products, two approvals
The core X API (the pay-per-use v2 platform covered in our developer account approval guide) and the X Ads API are documented, approved and authenticated separately. Having a working developer account and app is only step one. X’s own getting-started guide is explicit: at that point you have “basic access to the X API, but not specific X Ads API functionality.” Every developer app that needs Ads API access has to be submitted individually through the Ads API Access Form and reviewed by the X team — there is no automatic upgrade path from a standard developer account.
Where ad-tech and agency builds get stuck
- A different OAuth generation entirely. Our OAuth 2.0 setup guide covers PKCE and the Authorization Code Flow used by the core X API. The Ads API uses none of that — every authenticated request needs an OAuth 1.0a Authorization header, generated over a three-legged flow. Teams that build their auth layer around OAuth 2.0 first have to build a second, separate authentication system to reach a single ad account.
- Two account types, one confusing word. X’s docs use “account” for both the advertising account (registered on business.x.com, identified by account_id) and the X user account making the request (identified by user_id). A request scoped to the wrong ID fails in a way that looks like a permissions bug, not a naming mix-up.
- App-level tier does not equal what one user can do. Standard Access at the app level covers Analytics, Campaign Management, Creatives, Custom Audiences and Conversion endpoints. But every individual connected to a specific ad account also carries an account-level role — Account administrator, Ad manager, Campaign analyst, Organic analyst or Creative Manager — and that role, not the app tier, decides what they can actually touch on that account.
- Promoted-only posting needs an extra grant. Using your own developer OAuth token against an advertiser’s account (rather than the advertiser’s own token) only lets you create Promoted-Only Posts if your username was separately granted the Post delegation/composer permission on business.x.com — visible via the TWEET_COMPOSER value on the account’s authenticated-user-access endpoint.
- Legacy apps carry narrower, differently-named tiers. Apps approved before July 2023 may hold only one of the old named permissions — Analytics read-only, Campaign Management & Creative, Custom Audiences, or Conversion — and may be capped at five OAuth tokens. There is no self-serve upgrade for either limit; both require reaching an X representative directly.
- No rate-limit increases, ever. X states plainly that it does not raise rate limits for any Ads API endpoint, regardless of access tier or spend. Scaling plans have to work within the published ceiling from day one, not assume a request for more room later.
How access actually gets requested
Start from a working developer account and app
The Ads API Access Form is submitted per developer app, so the underlying app, keys and tokens (see our developer account guide) have to exist and be stable first.
Choose the access tier deliberately
Conversion Only unlocks Mobile and Web Conversion endpoints. Standard Access unlocks Analytics, Campaign Management, Creatives, Custom Audiences and Conversion together. The tier requested shapes every endpoint available afterward — there is no per-endpoint pick-and-choose.
Plan the OAuth 1.0a layer before, not after, approval
Whether requests will run on the advertiser’s own access token (the recommended, three-legged flow) or a developer token added to the advertiser’s account changes what the app can do — including whether it can post promoted-only content.
Regenerate tokens once approved
X’s own guide is explicit that access tokens issued before approval will not carry Ads API permissions — they have to be regenerated after the app is approved before any authenticated Ads API request will succeed.
The exact answers that get a Standard Access request approved on the first pass — how the use case is described, which endpoints are actually justified, and how the OAuth 1.0a flow is structured for an agency serving multiple advertiser accounts — is deliberately not spelled out here.
What getting this wrong actually costs
- A second authentication system to build. OAuth 2.0 work already done for the core X API does not carry over — OAuth 1.0a signing, three-legged authorization and Twurl-style testing are a separate implementation.
- Resubmission per app, not per account. Every developer app needing Ads API access needs its own approved request — multi-app architectures multiply the review process rather than sharing one approval.
- A hard token ceiling with no self-serve fix. Pre-July-2023 apps limited to five OAuth tokens, or to a narrow legacy permission tier, can only be raised by reaching an X representative directly.
- Silent posting failures. An app authenticated with the wrong OAuth token type, or missing the composer permission grant, can pass basic authentication and still be unable to create Promoted-Only Posts — a failure mode that looks like a bug rather than a missing grant.
Structuring the access-tier request, the OAuth 1.0a flow and the account-permission model correctly before the first submission is exactly what our X API setup and approval support covers. If OAuth scopes versus app-level permissions on the core API are still unclear, our scopes vs app permissions guide is the companion piece to this one.
Frequently asked questions
Does a standard X API developer account include Ads API access?
No. X’s own documentation states a developer account and app provide basic X API access only. Ads API functionality requires a separate, per-app request reviewed by the X team.
Can I use OAuth 2.0 for the Ads API?
No. Every authenticated Ads API request requires an OAuth 1.0a Authorization header. The OAuth 2.0 Authorization Code Flow with PKCE used elsewhere on the X API does not apply here.
What is the difference between app-level and account-level permissions?
App-level access (Conversion Only or Standard Access) is granted to the developer app itself. Account-level permissions (Account administrator, Ad manager, Campaign analyst, Organic analyst, Creative Manager) are granted per user on a specific advertising account, and determine what that user can actually do there.
Can X increase my Ads API rate limits?
X states it does not increase rate limits for any Ads API endpoint, regardless of access tier. Integrations need to be designed around the published limits rather than a future increase.
Facts here are based on official X (Twitter) Ads API developer documentation — the Ads API step-by-step guide, Accessing Ads Accounts, Making Authenticated Requests, and Increasing Access pages — reviewed August 2026. This is technical implementation guidance, not legal advice, and is not affiliated with or endorsed by X Corp. X makes all Ads API access and approval decisions independently; no specific outcome or timeline can be assured. Need help getting X Ads API access approved and connected? Reach out through the contact options in the footer.