#1

Hello, I’ve returned to complain more about working with the v2 API.

I hope these complaints eventually lead to change so future developers have an easier time getting the data they seek.

Previously I complained about:

  • linking campaigns with tweets in order to get the current promoted status of a tweet
  • calls failing when one parameter is restricted rather than returning the allowable data
  • requesting data on multiple promoted tweets randomly throws errors even when requesting the same data on them individually does not. This is definitely a bug that has been ignored.

Now I’ve returned to explain one more hurdle we’re facing with API v2.

Our goal:
Get all available fields for all of our tweets in the last 6 months. Retrieve newer tweet data more frequently than older tweets.

Tweet types:

  • promoted under 30 days old
  • not promoted under 30 days old
  • all tweets over 30 days old

Our process:

  1. Ask for all tweets 6 months to 1 month old. This part is easy because we know what metrics will return for all variety of tweets whether promoted or not.
  2. Ask promoted_tweets endpoint for promoted tweets
    • this returns promotion campaigns rather than just the promotion status of a tweet
    • we still need to dedupe this data in case there were multiple campaigns or start and stopped campaigns on the same tweet
    • if a tweet was promoted once and then stops being promoted it will still return in this list
  3. Ask for all tweets under 30 days old with the allowable metrics (not promoted metrics). The tricky part is we then have to remove the promoted tweets from this data because we will later request promoted tweets with the promoted fields.
  4. Ask for promoted tweets under 30 days old with the promoted metric.

The problem with steps 3 and 4 is that we only know if a tweet was ever promoted, not if it’s currently promoted.

So, if we start pulling a tweet that is not promoted everything is fine. It’s in the <30 day not promoted group. Then we promote it and it moves into the <30 day promoted group. Then if we stop promoting it within the same 30 days…

There’s really know way (that I know of please prove me wrong) to programatically figure that out ahead of time. Instead, our promoted metric calls to the id will start failing because we’re calling a promoted metric on a no longer promoted tweet (even though that id is still returned by the promoted_tweets endpoint).

Dear Twitter Dev’s, any one of these features would make this workflow way better:

  1. A dedicated endpoint to know which tweets are currently promoted
  2. Not failing a call when only some of the metrics are not allowed for certain ids. Instead just return NULLs for the disallowed metrics and return data for the allowed metrics. That would make this process way easier.
  3. Some sort of bulk data export that gives all available tweet and media metrics for all owned tweets within a certain time range.
3 Likes