If you don’t already have a dev environment created, simply click Set up dev environment, type a label and assign it to an app. The label can be anything, but make sure you remember it because you’re going to need it for later.

You will need to get your access tokens from your Twitter app dashboard. From the app that contains the environment you just created, click Details, then click Keys and tokens. Make a note of the values reported under:

• API Key (aka Consumer Key)
• API Secret Key
• Access Token
• Access Token Secret
   

Create a file in your home folder called .env.twitter, and add the values you found in that page, plus your environment label:

Developers are often confused by Consumer Keys (aka API Keys) and Access Tokens. Long story short, think of those as if they were encrypted username and passwords. A Consumer Key/Secret pair are identify your app, while Access Tokens are user credentials. This means your Consumer Key/Secret do not change, but your Access Token/Secret changes based on the user who’s authenticating with your app.

You’ve probably noticed that if you’re the owner of your own app, TWITTER_ACCESS_TOKEN and TWITTER_ACCESS_TOKEN_SECRET identify yourself. If that’s the case, you don’t really have to go through OAuth to identify yourself – we already generated those tokens for you (keep that in mind, it’s going to come in handy later).
 

Install Autohook

Next, we’ll install Autohook. Its package is available from both npm and Yarn.

I almost wish there were more steps, but that’s it. Autohook is that easy!
 

Create a new project

We’ll start with a new project. We’re setting it up in your home folder, but naturally it can live anywhere:

Let’s create a file named index.js. We’ll add code to call Autohook and make sure everything is configured as intended. Just so we can start with a clean environment, this code will remove all existing webhooks from your environment. If you don’t want to lose your existing webhooks, choose a different dev environment from your developer dashboard. As an alternative, you can remove the call to removeWebhooks(), and replace start() with startServer().

Save and run your file. 

Behind the scenes, Autohook handled OAuth for us. It also ran a development server with logic to create a webhook and to validate the CRC signature. And because we provided your access token/secret, it also subscribed your app to listen to your user’s activity (it did come in handy)!

What can go wrong at this point? The most common pitfall is that the authenticating user won’t authenticate. Remember, users need to authorize your app before it can access their activity; if you’re trying to authenticate a test user (or even better, if you’re asking a friend to help you test your app), make sure they’re authenticating using Sign In With Twitter and the 3-legged OAuth flow. Autohook’s got your back – you can find a sample implementation on the project’s page.

If you bump into an error, most likely your credentials are not set correctly; check your .env.twitter and try again. If you’re still stuck, come visit the Twitter Community forums and we’ll be more than happy to help you out!
 

Detect and filter incoming events

Now that Autohook took care of the underlying wiring, it’s time to focus on our app logic. The Account Activity API can ping your webhook with many activity types, so it’s important we only react to the activity type related to an incoming message.

Since you’re using Autohook, you can listen to an incoming event listener – The event name is just event.  Add this right before the call to removeWebhooks():

If you run your code now, nothing may seem to happen at first. But try and like a Tweet and something like this will show up in your Terminal:

Because your app subscribed to your user’s activities, we received that activity in realtime. The object is always starts with for_user_id, which indicates a user ID (if you subscribe to multiple users, this is how you know which user this activity belongs to). The actual activity is described by a dictionary key. In this case, we received a key  named favorite_events because we just liked a Tweet. There are many activities, like tweet_create_events, follow_events, and direct_message_events just to mention a few. In Autohook, these values will all be event keys in your event object from the listener. So if we want to listen to direct messages only, all we have to do is to explicitly detect those events:

In this case, we will only process direct message events, and we’ll send the details to a function named sayHi(). This function will process the event and shoot a DM back waving hi to any incoming direct message!
 

Say hi 👋

We'll create a message to wave hi back to our friend who just messages us. But how do we know who’s the sender, and how can we be sure this message is directed to our account? Thankfully, the Direct Message event will contain full details about both parties involved in the conversation. You already have the OAuth credentials of the recipient (yourself), which is all you need to send a message back by means of sayHi(). The logic for this function is straightforward:

• We’ll double check that the Direct Message event is valid and was intended for to your user. You don't really need to do this since this code will only work with your user credentials, but it will be useful to implement in case you want to expand your code to make it say hi for other accounts.
• We’ll only listen to incoming messages (outgoing messages generate an activity too, and we want to filter those out otherwise we’ll run into an infinite loop).
• We’ll say hi!
   

To check that the message is valid, we’ll need to check that the message object exists and contains a message_create key. This key contains all the relevant details about the message, including the sender and recipient IDs, and the message itself. We’ll also check the sender and recipient’s details, and if they’re the same, it means you are sending a message to yourself. If this happens, the autoresponder we’ll say hi to you, which in turn will cause the autoresponder to say hi to you, which in turn will cause the autoresponder to say hi to you… causing an infinite loop. It’s actually easier done than said:

All we have to do next is to prepare the request body for the message reply and send it as using the Direct Messages API. The request body of this API has the exact same format of an Account Activity message response, which makes it easy to consume and produce.

This is it! Run your code and ask a friend to send you a message. You should see an incoming message, followed by an automated direct message:

Mark as read and typing indicator

Our code so far is about 80 lines of code, so we have plenty of room to implement all the fancy things an autoresponder can do. Direct Messages on Twitter can indicate when a message has been read (it’s the blue check next to the message timestamp). Since our autoresponder will read an incoming message for us, it would be nice to tell the sender our autoresponder read our message and that it’s about to reply.

Because the message body doesn’t have to be sophisticated, you will send these POST requests as form encoded, rather than sending raw JSON data like we did before.

To get the read check mark, we’ll simply extract the message ID from the activity we received earlier. Just like before, we’ll create the appropriate request body to send it to the Mark Read endpoint:

Similarly, we’ll now display a typing indicator which will present in the Direct Message window as a bubble with three dots. Since this is just an animation, there is no message attached to it; we will simply need to pass the ID of the person we want to show this bubble to the Indicate Typing API call.