Different oauth tokens per advertiser + rate limits

[CMP]

Recently my app has been running into “Status: 429 Too Many Requests” errors when hitting the https://ads-api.twitter.com/1/stats endpoint. I think this is because of an error on our end when generating new advertiser oauth tokens. I would like to confirm this is the case and how to address this problem.

Currently, for every client we onboard, we do the following:

1. Ask the client to add us as admins via their Twitter UI.
2. We sign in to Twitter as @pulsepointcmp via our platform as described here, thus generating and saving new set of oauth tokens for that client.
3. Every subsequent request for this client (creating campaigns, pulling numbers, etc.) is made with those tokens + the as_user_id param where appropriate (creating PromotedOnlyTweets, etc.).

The documentation states that "Using an Advertiser OAuth Token, rate limits are distinct per Advertiser and you can create Tweets on behalf of a User." This leads me to believe that each client should have its own x-rate-limit-remaining counter. However, I see that I only get 1 global counter that is always decremented, even when making requests with different clients/tokens.

Here are my questions:

1. Is the reason we’re seeing these global counters instead of one counter per client that we’re signing in as @pulsepointcmp every time instead of asking the client to sign in themselves with their credentials?
2. If so, would the solution for spreading out my current number of requests be as simple as asking them to sign in to Twitter via our app themselves, thus replacing the current token (which I suppose is tied to our account)?
3. Are there any pitfalls with regards to this switch? Will we be able to CRUD the current objects we’ve created using our tokens?
4. We would still like to have the ability to see the campaigns created in our clients’ Twitter Ads UI. Will we still need to have them give us admin rights to their account to do this?

Thanks.

[juanshishido]

Thanks for the detailed question, @CMP, and for looking into the documentation.

Before digging into the specifics, let’s describe the two ways to get access to an ads account. You can either (1) obtain OAuth tokens for the advertiser or (2) use your OAuth tokens with an ads manager role (e.g., account admin, ad manager, or analyst) (source). The first approach is preferred for the reasons you’ve stated. It sounds, based on, “[we ask] the client to add us as admins via their Twitter UI,” that you’re using the second approach.

Is the reason we’re seeing these global counters instead of one counter per client that we’re signing in as @pulsepointcmp every time instead of asking the client to sign in themselves with their credentials?

That’s correct. You’re using @pulsepointcmp’s authorization credentials and, thus, share the rate limit pool between all advertisers this user has access to.

If so, would the solution for spreading out my current number of requests be as simple as asking them to sign in to Twitter via our app themselves, thus replacing the current token (which I suppose is tied to our account)?

What you need to do is generate the OAuth tokens for the user who owns the ads account using the same process you describe above. When making a request to the Ads API, you need four pieces of information: consumer_key, consumer_secret, token, and secret. The first two are associated with the app and the second two are user-specific. The first approach I described above requires you to use the user-specific token and secret; the app credentials won’t change.

Are there any pitfalls with regards to this switch? Will we be able to CRUD the current objects we’ve created using our tokens?

No pitfalls with this approach. Yes, you’ll be able to create, read, update, and delete ads entities the authenticated user has access to.

We would still like to have the ability to see the campaigns created in our clients’ Twitter Ads UI. Will we still need to have them give us admin rights to their account to do this?

Any ads entities created under the account belongs to that account and can be accessed via the API regardless of the method you’re using.

We hope this helps clarify things. Please let us know if you have other questions or need additional clarification.

Thanks!

[CMP]

Gotcha. Sounds like our setup is the proper one except that each client should be signing in instead of us. In fact, I just noticed that all generated OAuth tokens are exactly the same—makes total sense! I will have our clients sign in themselves then.

Thanks for the clarification!

[juanshishido]

Perfect! It was a good question and one that will help other developers for sure. Thanks!