There are several different paths that you may take in getting access to an advertiser’s account when running campaigns. This document is a brief overview of the differences between these options and should be used in conjunction with our other resources.
It is important to note that all requests to the Ads API use application-user based OAuth. Therefore all options outlined below are utilizing OAuth 1.0A to access the API. It is recommended that you familiarize yourself with our obtaining access tokens documentation prior to settling on what method makes the most sense for your application.
As an Ads API developer, you should never request that our advertisers share their login credentials with you. The access options outlined here should negate any need for requesting such private information from any Twitter user.
This is the method we highly recommend for the majority of Ads API developers to gain access to an advertiser account. It allows you to call the API on behalf of a user and take actions as that user. These tokens do not expire, but can be revoked by the user at any time.
There are several ways to obtain the advertiser’s access tokens. The most common method is via OAuth 3-legged auth, directly from within your web UI. For developers whose UI is not exposed to advertisers, some do implement OAuth PIN-based auth. We recommend the 3-legged approach.
This option involves the advertiser granting your handle (or handles) access to their ads account via the Twitter UI at ads.twitter.com. This permission allows you to call the API using the OAuth tokens of your own handle rather than the advertiser’s. The key distinction on this option is that you may only create Promoted-Only Tweets if the Tweet delegation/composer permission has been granted to your handle.
Note that only
Account Administrator and
Ads Manager privileges enable access to an account via the Ads API.
Analyst and other permissions are not supported via API.
What are the differences between these methods?
|Advertiser (User) OAuth Token||
|Access Ads Account||✔||✔|
|Create Tweets on Behalf of User||✔||✔*|
|Create Cards on Behalf of User||✔||✔|
|Developer Access via Twitter Ads UI||✔|
|Rate Limits||Distinct per Advertiser||All Advertisers Utilize Single Rate Limit|
* see Developer OAuth Token (Ads Manager Role) below for details.
The standard flow is web-based and uses the 3-legged authorization OAuth flow. The screen shots outlined here are part of a sample that you can view the source of at https://github.com/jaakko-sf/twauth-web.
At some point in your application, you will want to redirect to Twitter in order to authorize your application When you redirect to Twitter with the request token, the user will be prompted to authorize your application Upon authorizing your application, the user will be redirected to the callback URL provided when you generated the request token. You will use this to obtain the permanent access token for this user and store it locally
To gain access using an Ads Manager Role granted to you by the advertiser, you’ll still need to use OAuth, but you’ll use your own tokens. See the options available to you at obtaining access tokens.
The advertiser will grant your handle access to their account using the ads.twitter.com UI. See our Advertising Help Center FAQ on multi-user login for details on that set-up process.
To gain access to create Promoted-Only Tweets on behalf of the
FULL promotable user on the account, you must also grant access to create Tweets in this flow. That will enable access via the
TWEET_COMPOSER permission on the GET accounts/:account_id/authenticated_user_access endpoint.