How are desktop or mobile apps supposed to use the Activity API?



Webhooks are fine for server applications. They are basically incompatible with desktop or mobile applications.

Is Twitter effectively killing off 3rd desktop and mobile applications unless they are priced high enough to include a backend server to handle the webhooks and implement their own streams?

Somehow, this seems utterly crazy, but I can see no other answer if User and Site streams are gone and only replaced by webhooks.


Hi @eliasisrael! What is the use case you’re describing in detail here, from the perspective of what you are attempting to implement? We’ve worked with many partners throughout this process and we do understand that removing these API options may be problematic, but in the vast majority of cases we believe that webhooks are the best option for the use cases in scope.

User and site streams have proven not to be scalable on the server side, and we are sorry that you’re disappointed in the decision to discontinue these outputs.

We recognise the desire to receive account actions, so we’ve taken the decision to provide webhooks for these, and from the feedback received so far these have proven to be successful and welcome to the apps that are implementing these connections.


As you may remember, we created Meshfire as a web application and service to give community managers an AI tool for sifting through the huge volume of tweets, both those directed at them via mentions and retweets, and those from key users they follow.

That business sadly didn’t succeed as a web service, though I have shown the technology to many others and impressed them with its capabilities.

One possible way to revive Meshfire, or so I thought, would be to port it to a standalone desktop application. It would have to receive the live timeline stream for the user and sort all of the incoming data using the AI technologies that we created.

A desktop application, however, cannot receive webhooks. It would have to be backed by a server somewhere to receive the webhooks and send websocket or push notifications. That is technically feasible, but not economically feasible unless one charges an ongoing subscription price, which is basically impossible for a desktop application.

As you have noted elsewhere, polling would be a fallback, but one can only poll once per minute (and, for safety’s sake, really once every 65 seconds), which introduces unacceptable lag into the user experience.

And even if that fallback were not too slow, it lacks key information that one needs to even comply with Twitter guidelines on the presentation of timelines. To wit, removing from display any tweets tht have been deleted by their authors. And that’s only the beginning.

And from my reading of the migration guide it’s not even clear that tweets on a person’s timeline would even appear in the activity api.

Please, please, tell me I’ve got this all wrong somehow.