All good things come to an end, including Twitter.stream (sigh 😔). Here’s how to make the most of it.
As a developer, you often times have to have access to data to make the most of applications you’re working on. Twitter happens to be a place where you can get plenty of it. Until the August 16 update to Twitter’s API, user and site streams were a great way go to get input data for a lot of apps.
But both of those are no longer options, and developers big and small have taken note. Apps like Tweetbot, Twitteriffic, and Talon that mimic Twitter’s own mobile app are the most affected, with them only able to service customers using Twitter’s new Account Activity API. After the August update, they’ll have to limit app notifications to 15 Twitter accounts in the free tier, or subscribe to the $2899/mo premium tier for 250 Twitter accounts ($16/user to break even). Hardly a viable option for such apps.
But if your app doesn’t mimic the Twitter app’s functionality, and doesnt need notifications from lots of users, then the new update has some benefits you can leverage. Before we get there though, lets go through how you can set up the new Account Activity API.
Webhook, line, and sinker
If you’re a developer who needs to access info from Twitter, and you don’t need to have notifications from large number of accounts, webhooks offer a great way to get the job done.
The first step you’ll need to take is securing your webhook. Twitter’s webhook-based APIs provide two methods for confirming the security of your webhook server:
- The challenge-response checks enable Twitter to confirm the ownership of the web app receiving webhook events.
- The signature header in each POST request enables you to confirm that Twitter is the source of the incoming webhooks.
Lets focus on the first option.
In order to verify that you are both the owner of the app and the webhook URL, Twitter will perform a Challenge-Response Check (CRC), which is not to be confused with a cyclic redundancy check. When a CRC is sent, Twitter will make a GET request of your web app with a ;
crc_token parameter. When that request is received, your web app needs to build an encrypted
response_token based on the
crc_token parameter and your app's Consumer Secret (details below). The response_token must be encoded in JSON (see example below) and returned within three seconds. When successful, a webhook
id will be returned.
A CRC will be sent when you register your webhook URL, so implementing your CRC response code is a fundamental first step. Once your webhook is established, Twitter will trigger a CRC on an hourly basis. Your app can also trigger a CRC when needed by making a PUT request with your webhook
id. Triggering a CRC is useful as you develop your webhook application, after deploying new code and restarting your service.
crc_token should be expected to change for each incoming CRC request and should be used as the message in the calculation, where your Consumer Secret is the key.
In the event that the response is not posted within 3 seconds or becomes invalid, events will cease to be sent to the registered webhook.
The CRC request will occur:
- When a webhook URL is registered.
- Approximately hourly to validate your webhook URL.
- You can manually trigger a CRC by making a PUT request. As you develop your webhook client, you should plan on manually triggering the CRC as you develop your CRC response.
Here’s what that might look like, if you’re working with JS:
Using the command line example scripts
These scripts should be executed from root of the project folder. Your environment, url or webhook ID should be passed in as command line arguments.
1- Create webhook config.
node example_scripts/webhook_management/create-webhook-config.js -e <environment> -u <url>
2- Add a user subscription for the user that owns the app.
node example_scripts/subscription_management/add-subscription-app-owner.js -e <environment>
3- To add a user subscription for another user using PIN-based Twitter sign-in.
node example_scripts/subscription_management/add-subscription-other-user.js -e <environment>
Note: More example scripts can be found in the example_scripts directory to:
- Create, delete, retrieve and validate webhook configs.
- Add, remove, retrieve, count and list user subscriptions.
When you set up your webhook, you’re able to specify specific events where Twitter will send you pieces of data. The best part about this it does not count against your allocated requests, so no charges!
I put this to use through an app I’m building right now to help people find food trucks near them. Using the Twitter Account Activity API, I can subscribe to a food truck’s Twitter account, and update their location on a custom Google Map by looking at the geolocation data in the tweet json. You can find that project on github.
Feel free to comment below with any questions and comments, and please like and subscribe if you like this kind of content 😛.
A bit about myself!
I’m a developer and recent graduate from Lambda School, a 7 month dev bootcamp that focuses on project based learning, especially team based projects, and am currently interested in full-stack roles.