アカウントアクティビティAPIは、Twitterユーザーのアカウントアクティビティに関連するイベントをリアルタイムで送信します。たとえば、受信登録したユーザーによるツイートの作成または削除、リツイート、ダイレクトメッセージの送受信、新しいユーザーのフォロー、投稿への「いいね」があるたびに、アカウントアクティビティAPIからJSONイベントペイロードが配信されます。アカウントアクティビティAPIが処理するアクティビティの種類の完全なリストについては、Twitterの開発者向けドキュメントを参照してください（プレミアムとエンタープライズ）。

アカウントアクティビティAPIはTwitterのRESTやストリーミングAPIとは異なり、複数のRESTエンドポイントを組み合わせて設定と管理を行い、データ配信にはWebhookを使用します。Webhookでは、登録済みWebアプリケーションのWebhook URLにイベントを「プッシュ（POST）」することでデータを配信します。これは、特定のイベント（アカウントアクティビティ）がTwitter上で発生したときに、リアルタイムでHTTP呼び出しを行うことで実現されます。

Twitterのより一般的なAPIはクライアント-サーバーアプローチに基づいており、開発者はTwitterのサーバーに接続して情報を受信するクライアントアプリケーションを作成します。これによりストリーミングモデルをベースにすることができます。この場合、クライアントとTwitterのサーバーの間の接続は常時開いており、リアルタイムでデータを受信します。また、開発者が特定のツイートオブジェクトを取得したい場合などにはクライアントがトリガーするリクエストにすることもできます。

アカウントアクティビティAPIではこれが逆になります。クライアントアプリケーションからTwitterのサーバーに接続リクエストを行うのではなく、データをリッスンする開発者のWebアプリケーションWebhookへの接続をTwitterのサーバーから行います。このケースでは、Twitterがクライアントとして機能し、開発者のサーバーへの接続を開いてイベントが発生するたびにそのWebhookにアクティビティを投稿します。

WebhookベースのAPIには多くのメリットがあります。

• コンピューティングリソース確保の観点から見ると、ストリーミングAPIに対して継続的に接続を開く場合よりも、Webhookでは必要なリソースが少なくなります。
• HTTP 200応答コードでPOSTごとに配信されるアクティビティの両サイドで確認が行われます。
• アクティビティの配信に失敗した場合に備えて、POSTを再実行するための再試行プロセスが組み込まれているため、データ損失が発生する可能性が低くなります。
• Webhookでは、新しいデータが利用可能かを確認するために、アプリケーションからAPIに対して定期的にポーリングリクエストを行う必要がありません。
• 新しいデータが利用可能になり次第、自動的にサーバーに送信されます。そのため、受信するデータはほとんどの場合最新のものになります。
  

アカウントアクティビティAPIの使用を開始するには以下が必要です。

• TwitterのどのAPIを使用する場合でも開発者アカウントが必要です。アカウントがない場合は申請してください。
• 適切な権限を持つTwitter開発者アプリ。開発者ポータルのアプリセクションにある [Create an app] ボタンを選択して、新しいアプリを作成できます。
  • アプリページの権限のタブで [Read, Write, and Access Direct Messages] を有効にします。過去により低い権限が設定された認証済みユーザーに権限設定が遡って適用されることはありません。
  • [Keys and Access token] タブで、アプリのコンシューマーAPIキーとAPIシークレットをメモします。この情報は、ベアラートークンの生成に必要です。
  • アプリのアクセストークンとアクセストークンシークレットも生成する必要があります。Webhook URLを登録する際に、これらが必要です。 
• 開発者ポータルの [developer environment] セクションで設定できる開発環境。アプリを選択し、環境名を選択します。別のアカウントアクティビティAPIエンドポイントの使用を開始すると、:env_nameトークンが選択した名前に置き換わります。
• Webhookを通じてデータを受信するためのURLを持つセキュリティ保護された専用Webアプリケーション。開発環境でWebhookをテストするためのローカルWebアドレスを作成するには、ngrokなどのツールが役に立ちます。

Webhook経由でTwitterからアクティビティを受信するには、指定したURLでHTTP（POSTとGET）リクエストを受信できるWebアプリケーションを作成し、セキュリティ保護する必要があります。アカウントアクティビティAPI用の開発者環境で設定したのと同じTwitterアプリ認証情報でこのWebアプリケーションを保護し、これらの認証情報を使用してcrc_tokenを作成するようコーディングする必要があります。Twitterではお使いのWebhookにチャレンジレスポンス方式のチェック（CRC）のGETリクエストを頻繁に送信します。これに対応するために、Webアプリケーションでは承認済み開発者環境アプリと一致するTwitterアプリケーション認証情報を使って生成されたcrc_tokenを返す必要があります。

POST account_activity/all/:env_name/webhooksエンドポイントを使用して、アカウントアクティビティAPIのWebhook URLを登録できます。

アカウントアクティビティAPIの設定はすべてAPIリクエストで行います。開発者ポータルには、ユーザーインターフェイスは組み込まれていません。ただし、テスト用に、TwitterDev GitHubページ（https://github.com/twitterdev/account-activity-dashboard）にサンプルダッシュボードツールが用意されています。

アカウントアクティビティAPIは、イベントデータを含むHTTP POSTリクエスト形式で、選択した登録済みWebhook URLからアカウントアクティビティを送信します。

APIの機能ごとに認証方法が異なるため、アカウントアクティビティAPIの認証は複雑になる場合があります。大半のWebhook設定は、ベアラートークンを使用したアプリケーション専用認証によって行います。必要なベアラートークンの生成方法に関する、Twitterのドキュメントを参照してください。

サブスクリプションの設定は、各ユーザーサブスクリプションのアプリケーション-ユーザー間認証を通じて行います。自身のTwitterアカウントのイベントを受信する場合は、開発者ポータルのAPIキーとAPIシークレットキーで生成したアクセストークンを使用できます。これはAPIの使用開始とテストに最適な方法です。ただし、別のTwitterアカウントに関連するイベントを受信するには、そのアカウントの所有者から3-Legged OAuthプロセスを通じて権限を付与してもらう必要があります。このプロセスはサーバー側のコードにも実装する必要があります。これを行うことでユーザーのアクセストークンを受信できるようになります。

Webhook URLへの受信登録が完了すると、ユーザーのイベントを受信するようになります。そもそもイベントとは何なのでしょうか？この場合、イベントとは受信登録したユーザーのTwitterアカウントに関連するアクティビティを指します。各イベントはアプリで使用できるJSONペイロード形式で配信されます。以下のサンプルにあるとおり、ユーザーがダイレクトメッセージを受信すると「message_create」イベントが配信されます。メッセージの内容やその他の情報を含む「text」フィールドがあります。