Account Activity API: Enterprise

このエンドポイントは、ポスト編集メタデータを含むように更新されました。これらのメタデータの詳細については、“ポストを編集” の基礎ページをご覧ください。このエンドポイントは、Direct Messages エンドポイントと併用されることがよくあります。新しい v2 Direct Messages エンドポイントを公開しました。Enterprise と Premium Account Activity API は v2 の 1 対 1 メッセージをサポートしていますが、グループ会話はまだサポートしていません。

概要 Enterprise Account Activity API は、webhook を介してユーザーアカウントに関連するリアルタイムのアクティビティをサブスクライブできる機能を提供します。これにより、単一の接続を通じて、保有またはサブスクライブしている 1 つ以上のアカウントから、リアルタイムのポスト、Direct Messages、その他のアカウントイベントを受信できます。 webhook を登録している各ユーザーサブスクリプションごとに、以下のすべての関連アクティビティを受信します。

Activity types
* ポスト (ユーザーによる) * ポスト削除 (ユーザーによる) * @メンション (ユーザー宛て) * 返信 (ユーザーから、またはユーザー宛て) * リツイート (ユーザーによる、またはユーザー宛て) * 引用ツイート (ユーザーによる、またはユーザー宛て) * 引用ツイートのリツイート (ユーザーによる、またはユーザー宛て) * いいね (ユーザーによる、またはユーザー宛て) * フォロー (ユーザーによる、またはユーザー宛て) * フォロー解除 (ユーザーによる)	* ブロック (ユーザーによる) * ブロック解除 (ユーザーによる) * ミュート (ユーザーによる) * ミュート解除 (ユーザーによる) * Direct Messages 送信 (ユーザーによる) * Direct Messages 受信 (ユーザー宛て) * 入力中インジケーター (ユーザー宛て) * 既読通知 (ユーザー宛て) * 購読取り消し (ユーザーによる)

注意 - Account Activity API 経由ではホームタイムラインのデータを配信しません。このデータを取得するには、GET statuses/home_timeline を使用してください。

動画シリーズ

Account Activity API を手早くキャッチアップするには、全4回の動画シリーズをご覧ください。

機能概要

ティア	料金	一意のサブスクリプション数	Webhook の数	信頼性とアクティビティ復旧
Enterprise	営業担当に問い合わせ	最大 500+	3 以上	再試行およびリプレイ

ご不明な点がありますか？エラーが発生していますか？
- FAQ (よくある質問) またはエラーのトラブルシューティングガイドを参照してください。
サンプルコードを試してみてください：
- Enterprise Account Activity API ダッシュボード：Enterprise ティアの Account Activity API を使用して webhook イベントを表示し、リプレイ機能も備えた Node 製の Web アプリです。
- SnowBot chatbot：Enterprise Account Activity API と Direct Message API の上に構築された Ruby 製の Web アプリです。

Webhook と購読ユーザーの管理

⏱ 読了時間 10 分 Enterprise Account Activity API は、あなたのサービスに購読している X アカウントでイベントが発生するたびに、webhook ベースの JSON メッセージを提供します。X はそれらのアクティビティを、登録済みの webhook に配信します。以下の手順では、webhook と購読ユーザーの管理方法を説明します。ここでは、webhook と購読ユーザーの登録、確認、削除の方法を説明します。各種 API エンドポイントへのリクエスト送信には、シンプルな cURL コマンドを使用します。cURL は、URL 構文を使ってリクエストの送受信を行うコマンドラインツールです。次のものが必要です:

登録済みの X App - こちらから登録
ベアラートークン - 詳しくはこちら
Challenge-Response Check (CRC) に合格する webhook - 詳しくはこちら
Enterprise アカウント - こちらから申請

作業を始める前に、X の Account Activity API を使い始めるためのサンプル Web アプリや補助スクリプトを提供しているこちらの GitHub リポジトリをご覧いただくことをおすすめします。

Webhook の管理:

Webhook を使用すると、単一の接続でユーザーアカウントに関連するリアルタイムのアクティビティを購読できます。

Webhook を追加する
Webhook を表示する
Webhook を削除する

まず、対象のアプリケーションコンテキストに対して新しい Webhook URL を登録します。URL は保存前に CRC リクエストで検証されます。Webhook を登録したら、後で必要になるため Webhook ID を必ず控えておいてください。次の項目を変更したうえで、以下の cURL リクエストをコマンドラインにコピーして実行してください。

URL <URL> 例: https://yourdomain.com/webhooks/twitter/
Consumer key <CONSUMER_KEY> 例: xvz1evFS4wEEPTGEFPHBog

Access token <ACCESS_TOKEN> 例: 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb

curl --request POST --url 'https://api.x.com/1.1/account_activity/webhooks.json?url=<URL>' --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<ACCESS_TOKEN>", oauth_version="1.0"'

指定したアプリケーションに登録されているすべての Webhook URL とそのステータスを取得するには、次のコマンドを実行します。次の項目を変更したうえで、以下の cURL リクエストをコマンドラインにコピーして実行してください。

ベアラートークン <BEARER_TOKEN> 例: AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...
--request GET --url https://api.x.com/1.1/account_activity/webhooks.json --header

指定したアプリケーションの設定から Webhook を削除するには、次の項目を変更したうえで、以下の cURL リクエストをコマンドラインにコピーして実行してください。

Webhook ID <:WEBHOOK_ID> 例: 1234567890
Consumer key <CONSUMER_KEY> 例: xvz1evFS4wEEPTGEFPHBog
Access token <ACCESS_TOKEN> 例: 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
--request DELETE --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>.json --header

購読ユーザーの管理:

Webhook を登録すると、Account Activity API に購読ユーザーを追加して、そのアカウントのアクティビティの受信を開始できます。

サブスクリプションの追加
サブスクリプションの確認
サブスクリプションの削除

すべてのイベントタイプを受信できるよう、まずユーザーをサブスクリプションに追加するところから始めます。次の項目を変更したうえで、以下の cURL リクエストをコマンドラインにコピーして実行します。

Webhook ID <:WEBHOOK_ID> 例: 1234567890
Consumer key name <CONSUMER_KEY> 例: xvz1evFS4wEEPTGEFPHBog

購読ユーザーのアクセストークン <SUBSCRIBING_USER'S_ACCESS_TOKEN> 例: 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb

curl --request POST --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>/subscriptions/all.json --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<SUBSCRIBING_USER'S_ACCESS_TOKEN>", oauth_version="1.0"'

指定した Webhook に対するすべてのアクティビティタイプのサブスクリプション一覧を表示するには、次の項目を変更したうえで、以下の cURL リクエストをコマンドラインにコピーして実行します。

Webhook ID <:WEBHOOK_ID> 例: 1234567890

ベアラートークン <BEARER_TOKEN> 例: AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...

curl --request GET --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>/subscriptions/all/list.json --header 'authorization: Bearer <BEARER_TOKEN>'

無効化後は、そのリクエストを行っているユーザーに関するすべてのイベントは Webhook URL に送信されなくなります。指定されたユーザーコンテキストおよびアプリケーションでサブスクリプションを無効化するには、次の項目を変更したうえで、以下の cURL リクエストをコマンドラインにコピーして実行します。

Webhook ID <:WEBHOOK_ID> 例: 1234567890
Consumer key <CONSUMER_KEY> 例: xvz1evFS4wEEPTGEFPHBog

購読ユーザーのアクセストークン <SUBSCRIBING_USER'S_ACCESS_TOKEN> 例: 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb

curl --request DELETE --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBED_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

これで、Webhook と購読ユーザーを管理できるようになりました。

参照記事

Challenge-Response Check (CRC) の概要
[Account Activity データ type](/x-api/enterprise-gnip-2.0/fundamentals/account-activity#account-activity-data-object-structure
Webhook とサブスクリプションの管理

Account Activity API のビデオウォークスルー

このビデオウォークスルーでは、Account Activity API の Premium および Enterprise ティアで利用できる機能について学びます。このビデオを見終えると、次の機能について理解できます。

webhook の登録
ユーザーサブスクリプションの追加
ユーザーサブスクリプションの削除
アカウントアクティビティの受信
アカウントアクティビティのリプレイ

質問がありますか？エラーが発生していますか？
- よくある質問またはエラーのトラブルシューティングガイドをお読みください。
サンプルコードを参照してください:
- Enterprise Account Activity API dashboard：Enterprise ティアの Account Activity API を使用して webhook イベントを表示し、Replay 機能を備えた Node.js 製の Web アプリです。
- SnowBot chatbot：Enterprise Account Activity API と Direct Message API を基盤として構築された Ruby 製の Web アプリです。

Enterprise

Webhook の利用を開始する

Account Activity API は、開発・デプロイ・ホストした Web アプリにアカウントイベントを送信する、Webhook ベースの API です。イベントコンシューマーアプリケーションで Webhook イベントの受信を開始する前に、いくつかの「下準備」となる作業があります。以下のとおり、X の App を作成し、Account Activity API へのアクセス権を取得し、Webhook イベントを受信して処理する Web アプリを開発する必要があります。

1. X App を作成する

開発者コンソールで承認済みの開発者アカウントを使用して X app を作成します。自社を代表して App を作成する場合は、企業用の X アカウントで App を作成することをお勧めします。開発者アカウントに申し込むには、こちらをクリックしてください。
App ページの permissions タブで「Read, Write and Access direct messages」を有効にします。
「Keys and Access Tokens」タブで、App の Consumer Key (API Key) と Consumer Token (API Secret) を控えておきます。
同じタブで、App の Access Token and Access Token Secret を生成します。これらの Access Token は、X がアカウントイベントを送信する先となる webhook URL を登録する際に必要になります。
X Sign-in や、X API におけるユーザーコンテキストの仕組みに不慣れな場合は、Obtaining Access Tokens を確認してください。イベントを受信するアカウントを追加するときは、そのアカウントの Access Token を使用して購読を行います。
開発者コンソールの “Apps” ページに表示されている App の数値 ID を控えておきます。Account Activity API アクセスを申請する際に、この App ID が必要になります。

2. Account Activity API アクセスを取得する

X App を作成したら、次のステップは Account Activity API へのアクセスを申請することです。 Account Activity API は Enterprise でのみ利用可能なため、以下のリンクから申請を行う必要があります。

3. Webhook コンシューマー App を開発する

Account Activity API へのアクセス権を取得したら、X の webhook イベントを受信する Web アプリを開発し、デプロイしてホスティングする必要があります。

イベントを受信するための webhook として使用する URL を持つ Web アプリを作成します。これは、X の webhook からの着信イベントをリッスンするためにサーバー上にデプロイするエンドポイントです。
- URI の path は自由に決めてかまいません。次の例は有効です: https://mydomain.com_/service/listen_
- さまざまなソースからの webhook を受信する場合、一般的なパターンは次のとおりです: https://mydomain.com/webhook/twitter
- 指定する URL にはポート指定を含めることはできない点に注意してください (https://mydomain.com:5000/NoWorkie は不可)。
Securing Webhooks ガイドに記載されているとおり、最初のステップは X Challenge Response Check (CRC) の GET リクエストを受信し、正しくフォーマットされた JSON レスポンスで応答するコードを書くことです。
Webhook の URL を登録します。/webhooks.json?url= エンドポイントに対して POST リクエストを送信します。このリクエストを送信すると、X は Web アプリに CRC リクエストを送信します。Webhook が正常に登録されると、レスポンスには webhook id が含まれます。この webhook id は、Account Activity API への一部のリクエストを行う際に後で必要になります。
X は、登録した URL にアカウントの webhook イベントを送信します。Web アプリが、着信イベントに対する POST リクエストをサポートしていることを確認してください。これらのイベントは JSON でエンコードされます。Webhook の JSON ペイロード例については HERE を参照してください。
Web アプリの準備ができたら、次のステップはアクティビティを受信するアカウントを追加することです。アカウントを追加 (または削除) する際には、アカウントの id を参照する POST リクエストを送信します。詳細は、サブスクリプションの追加に関するガイドを参照してください。

4. セットアップの検証

App と webhook が正しく構成されていることを検証するには、App がサブスクライブしている X アカウントのいずれかのポストに「いいね」を付けてください。サブスクライブしている各アカウントがいいねを受け取るたびに、webhook URL への POST リクエストを通じて favorite_events を受信するはずです。
サブスクリプションが追加されてからイベントの配信が開始されるまで、最大で 10 秒かかる場合があることに注意してください。

重要な注意事項

webhook URL を登録する際、Web アプリはコンシューマートークンとシークレット に加えて App オーナーのユーザーアクセストークンとシークレット で認証を行う必要があります。
すべての受信ダイレクトメッセージは webhook 経由で配信されます。POST direct_messages/events/new (message_create) を介して送信されたすべてのダイレクトメッセージも webhook 経由で配信されます。これは、別のクライアントから送信されたダイレクトメッセージも Web アプリが把握できるようにするためです。
すべての webhook イベントには、そのイベントがどのサブスクリプションに対して配信されたかを示すユーザー ID である for_user_id が含まれていることに注意してください。
同じ会話で 2 人のユーザーがあなたの Web アプリをダイレクトメッセージ用に利用している場合、webhook は 2 つの重複イベント (各ユーザーごとに 1 件) を受信します。Web アプリ側でこれを考慮する必要があります。
同じ webhook URL を共有し、同じユーザーが各 App にマッピングされている Web アプリが複数ある場合、同じイベントが webhook に複数回送信されます (Web アプリごとに 1 回) 。
場合によっては、webhook が重複したイベントを受信することがあります。webhook アプリはこれを許容し、イベント ID によって重複排除を行う必要があります。
Quick Reply の応答がリクエストに続けてすぐに返ってくることを想定しないでください。ユーザーは Quick Reply のリクエストを無視し、従来のダイレクトメッセージで返信することもできます。また、ユーザーはメッセージスレッド内で以前に返信していないリクエストに対して Quick Reply の応答を送信することもできます。
コード例はこちらを参照してください:
- Enterprise Account Activity API dashboard — Account Activity API のエンタープライズティアを使用して webhook イベントを表示する Node 製の Web アプリで、Replay 機能を備えています。
- SnowBot chatbot — Account Activity API と Direct Message API 上に構築された Ruby 製の Web アプリです。このコードベースには、Account Activity API の webhook セットアップを支援する script が含まれています。

Webhook のセキュリティ確保

X の Webhook ベースの API では、Webhook サーバーのセキュリティを検証するために 2 つの方法を提供しています。

challenge-response チェックにより、Webhook イベントを受信する Web アプリの所有権を X が確認できます。
各 POST リクエスト内の署名ヘッダーにより、受信した Webhook が X から送信されたものであることをあなたが確認できます。

チャレンジレスポンスチェック

あなたが App の所有者であり、かつ Webhook URL の所有者であることを検証するために、X は Challenge-Response Check (CRC) を実行します。これは巡回冗長検査 (cyclic redundancy check) とは別物です。CRC が送信されると、X は crc_token パラメータを付けてあなたの Web アプリに対して GET リクエストを行います。そのリクエストを受信したら、あなたの Web アプリは crc_token パラメータと App の Consumer Secret (詳細は後述) に基づいて暗号化された response_token を生成する必要があります。response_token は JSON でエンコードされている必要があり (以下の例を参照) 、3 秒以内に返さなければなりません。成功すると、Webhook の id が返されます。 Webhook URL を登録するときに CRC が送信されるため、CRC 応答コードを実装することは最初に行うべき基本的なステップです。Webhook が確立された後は、X は最後に正常な応答を受信してからおおよそ 24 時間ごとに CRC をトリガーします。また、あなたの App から Webhook の id を使って PUT リクエストを行うことで、必要に応じて CRC をトリガーすることもできます。CRC をトリガーすることは、Webhook アプリケーションの開発中や、新しいコードをデプロイしてサービスを再起動した後などに有用です。 crc_token は受信する CRC リクエストごとに変更されると想定しておく必要があり、計算時には Consumer Secret をキーとして、この crc_token をメッセージとして使用しなければなりません。 3 秒以内に応答が返されない場合、または応答が無効になった場合、登録済み Webhook へのイベント送信は停止します。

CRC リクエストが行われるタイミング:

webhook URL が登録されたとき。
webhook URL を検証するために、おおよそ 1 時間ごと。
PUT リクエストを送信することで、CRC を手動でトリガーできます。webhook クライアントを開発する際には、CRC レスポンスを実装しながら、この手動 CRC トリガーも行うことを想定しておいてください。

レスポンス要件:

crc_token と App の Consumer Secret から生成された、base64 エンコード済みの HMAC SHA-256 ハッシュ
有効な response_token を含む JSON 形式
3 秒未満の応答時間
HTTP 200 レスポンスコード

言語ごとの HMAC ライブラリ:

Python におけるレスポンストークン生成の例:

次のコードは、Flask ベースの Python 2.7 Web アプリで、challenge-response チェックに正しく応答するルートを定義しています。

import base64
import hashlib
import hmac
import json


\# Defines a route for the GET request
@app.route('/webhooks/twitter', methods=\['GET'\])
def webhook_challenge():

  # 受信トークンとコンシューマーシークレットからHMAC SHA-256ハッシュを作成します
  sha256\_hash\_digest = hmac.new(TWITTER\_CONSUMER\_SECRET, msg=request.args.get('crc_token'), digestmod=hashlib.sha256).digest()

  # base64エンコードされたハッシュを使用してレスポンスデータを構築します
  response = {
    'response\_token': 'sha256=' + base64.b64encode(sha256\_hash_digest)
  }

  # 適切にフォーマットされたJSONレスポンスを返します
  return json.dumps(response)

JSON レスポンスの例:

上記のようにルートが定義されている場合、Web ブラウザーで https://your-app-domain/webhooks/twitter?crc_token=foo にアクセスすると、Web アプリケーションは以下と同様のレスポンスを返します。

{
  "response_token": "sha256=x0mYd8hz2goCTfcNAaMqENy2BFgJJfJOb4PdvTffpwg="
}

その他の例:

こちらは、Node/JS で記述された CRC レスポンスメソッドの例です。
こちらは、Ruby で記述された CRC レスポンスメソッドの例です (generate_crc_response と、CRC イベントを受信する /GET ルートを参照してください) 。

署名ヘッダー検証 (オプション)

X からの POST リクエストを受信する場合、webhook を作成するために GET リクエストを送信する場合、または手動で CRC を実行するために GET リクエストを送信する場合、x-twitter-webhooks-signature というヘッダーでハッシュ署名が渡されます。この署名を使用して、データの送信元が X であることを検証できます。POST のハッシュ署名は sha256= で始まり、X App Consumer Secret とペイロードの暗号化に HMAC SHA-256 が使用されていることを示します。GET のハッシュは、クエリパラメータ文字列 crc_token=$token&nonce=$nonce から計算されます。 リクエストを検証する手順

consumer secret と受信したペイロード本体を使用してハッシュを作成します。
作成したハッシュを、base64 エンコードされた x-twitter-webhooks-signature の値と比較します。タイミング攻撃への脆弱性を減らすために、compare_digest のようなメソッドを使用してください。

追加のセキュリティガイドライン

以下は、Web アプリケーション向けに検討すべき追加のセキュリティガイドラインです。これらのガイドラインを実装していなくても webhook の動作自体が停止したりしなくなることはありませんが、X の情報セキュリティチームにより強く推奨されています。以下の推奨事項に馴染みがない、または内容がよく分からない場合は、サーバー管理者に相談してください。

X 集約ネットワークブロック

セキュリティをさらに強化するため、次の集約ネットワークブロックを許可リストに追加することを検討してください。

199.59.148.0/22
199.16.156.0/22
192.133.77.0/26
64.63.15.0/24
64.63.31.0/24
64.63.47.0/24
202.160.128.0/24
202.160.129.0/24
202.160.130.0/24

推奨されるサーバー設定

ssllabs.com のテストで “A” 評価を取得する
TLS 1.2 を有効化する
Forward Secrecy を有効化する
SSLv2 を無効化する
SSLv3 を無効化する (POODLE 対策)
TLS 1.0 を無効化する
TLS 1.1 を無効化する
TLS Compression を無効化する
セッションチケットキーをローテーションしていない場合は、Session Tickets を無効化する
SSL 設定で “ssl_prefer_server_ciphers” または “SSLHonorCipherOrder” オプションを “on” に設定する
暗号スイートの一覧が、次のような最新のリストになっていることを確認する: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA

Webhook およびサブスクリプションの管理

Webhook の作成と変更

Webhook の URL を変更するには、既存の Webhook を削除したうえで、新しい Webhook を作成する必要があります。また、その際は新しい Webhook に対してユーザーのサブスクリプションを再度追加する必要がある点に注意してください。

Webhook 設定管理エンドポイント:


メソッド	Enterprise
webhook URL を登録 / webhook_id を生成する	POST webhooks
すべての webhook URL とそのステータスを返す	GET webhooks
App の現在の webhook 設定を削除する	DELETE webhooks/:webhook_id
CRC リクエストを手動でトリガーする	PUT webhooks/:webhook_id

Webhook URL を更新するだけではだめなのはなぜですか？

Webhook の設定を変更できないのはなぜですか？ X はセキュリティを非常に重視しています。Webhook URL が変更されたということは、あなたのアプリケーションの consumer key と consumer secret が漏えいした可能性があることを意味します。新しい Webhook 設定の作成を必須にすることで、ユーザーのイベントへの購読を改めて行ってもらう必要が生じます。これには、悪意のある第三者が所持している可能性が比較的低い access token の使用が必要になります。その結果、第三者があなたのユーザーの非公開情報を受け取ってしまう可能性を低減できます。

User サブスクリプションの追加と削除

エンタープライズプランでは、数千件規模のサブスクリプションをサポートしています。すでにアカウントマネージャーがいる場合は、ご質問があれば担当のアカウントマネージャーまでお問い合わせください。エンタープライズ API へのアクセスを申請するには、こちらをクリックしてください。

サブスクリプション管理エンドポイント


メソッド	Enterprise
新しいユーザーサブスクリプションを追加する	POST webhooks/:webhook_id/subscriptions/all
ユーザーサブスクリプションを取得する	GET webhooks/:webhook_id/subscriptions/all
すべてのアクティブなサブスクリプションのリストを返す	GET webhooks/:webhook_id/subscriptions/all/list
アプリケーション専用 OAuth を使用してユーザーサブスクリプションを無効化する	DELETE webhooks/:webhook_id/subscriptions/:user_id/all.json

Account Activity API: Enterprise

ご注意ください: Account Activity API を利用開始する前に、まず X 側で開発者用 App に対して Account Activity API へのアクセスを有効化してもらう必要があります。そのため、認証に使用する予定の App ID をアカウントマネージャーまたはテクニカルサポートチームと必ず共有してください。

Account Activity API は、一連のエンドポイントで構成されており、単一の接続を通じて、サブスクリプション対象となっているすべてのアカウントのリアルタイムなアカウントアクティビティを受信するためのユーザーサブスクリプションを作成および管理できます。 Account Activity API では 2 つの認証方法 (OAuth 1.0a と OAuth 2.0 ベアラートークン) が利用可能です。どの認証方法を使用すべきかは、利用するエンドポイントによって異なります。


説明	エンドポイント	OAuth 1.0a (ユーザーコンテキスト)	OAuth 2.0 ベアラートークン (application-only)
指定したアプリケーションコンテキストに対して新しい webhook URL を登録する	POST account_activity/webhooks	✓
指定したアプリケーションについて、すべての URL とそのステータスを返す	GET account_activity/webhooks		✓
指定した webhook の URL に対して CRC (challenge response check) をトリガーする	PUT account_activity/webhooks/:webhook_id	✓
アプリケーションをユーザーアカウントのイベントを受信するよう登録する	POST account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
現在アクティブなサブスクリプション数を返す	GET account_activity/subscriptions/count		✓
webhook 設定がユーザーのイベントを購読しているかどうかを確認する	GET account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
現在アクティブなサブスクリプションのリストを返す	GET account_activity/webhooks/:webhook_id/subscriptions/all/list		✓
webhook を削除する	DELETE account_activity/webhooks/:webhook_id	✓
[非推奨] 指定されたユーザーコンテキストおよびアプリケーションに対するサブスクリプションを無効化する	DELETE account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
application-only OAuth を使用してサブスクリプションを無効化する	DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json		✓
アクティビティを webhook に再送信する	POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json		✓

*_ 認証には、サブスクライブしているユーザーの Access Token が必要です。 _ OAuth 1.0a のユーザーコンテキスト認証が必要なエンドポイントについては、リクエストを認証するために次の認証情報を指定する必要があります。

Consumer Keys (API Key と Secret)
Access Tokens (Access Token と Secret)

次の 3 つのエンドポイントでは、アプリケーションのコンテキスト内で書き込み操作を実行します (X ユーザーは関与しません) 。そのため、指定する必要がある Access Token は、あなたの開発者 App に属するものです。これらは開発者コンソール内の、該当する App の「Keys and tokens」タブから直接生成できます。

POST account_activity/webhooks: 指定したアプリケーションコンテキストに対して、新しい webhook URL を登録します
PUT account_activity/webhooks/:webhook_id: 指定した webhook の URL に対して CRC (Challenge Response Check) をトリガーします
DELETE account_activity/webhooks/:webhook_id: webhook を削除します

一方、以下の 3 つのエンドポイントでは、アプリケーションが X ユーザー (たとえばダイレクトメッセージなど) の保護されたデータに、ユーザーの代理としてアクセスできるようにするリクエストを送信します。そのため、対象となる購読ユーザーに属する Access Token を必ず指定する必要があります。必要な Access Token は、3-legged OAuth フローを使用して取得できます (OAuth 1.0a: how to obtain a user’s Access Tokens を参照) 。これらのエンドポイントは、上記の表ではアスタリスク (*) でマークされています。

POST account_activity/webhooks/:webhook_id/subscriptions/all: アプリケーションをユーザーのアカウントイベントに購読させます
GET account_activity/webhooks/:webhook_id/subscriptions/all: webhook 設定がユーザーのイベントを購読しているかどうかを確認します
DELETE account_activity/webhooks/:webhook_id/subscriptions/all: 指定されたユーザーコンテキストおよびアプリケーションのサブスクリプションを無効にします [非推奨]

ご注意: 開発者 App が「Read, Write, and Direct Messages」に有効化されていることを確認してください。この設定は、開発者アカウントの Projects & Apps セクションの、対象の開発者 App の「App permissions」で変更できます。権限設定を変更した後は、App の認証情報を再生成する必要があります。

Account Activity API で利用可能なすべてのエンドポイントの一覧 (説明および認証実装例付きのサンプル cURL リクエストを含む) は、APIリファレンスドキュメントで確認できます。さらに詳細な情報については、Enterprise Account Activity API を使い始める際に役立つ XDev のサンプル Web アプリとヘルパースクリプトも参照してください。

ご注意: Account Activity API を利用開始する前に、X 側で開発者 App に対して Account Activity API へのアクセスを有効化する必要があります。そのため、認証に使用する予定の App ID を、アカウントマネージャーまたはテクニカルサポートチームと必ず共有してください。

Account Activity API は一連のエンドポイントで構成されており、単一の接続を通じて、購読しているすべてのアカウントのアカウントアクティビティをリアルタイムで受信するためのユーザーサブスクリプションを作成および管理できます。 Account Activity API では、2 つの認証方法 (OAuth 1.0a と OAuth 2.0 Bearer Token) が利用可能です。使用すべき認証方法は、利用するエンドポイントによって異なります。


Description	Endpoint	OAuth 1.0a (ユーザーコンテキスト)	OAuth 2.0 ベアラートークン (アプリケーション専用)
指定されたアプリケーションコンテキストに対して新しい webhook URL を登録します	POST account_activity/webhooks	✓
指定されたアプリケーションに対するすべての URL とそのステータスを返します	GET account_activity/webhooks		✓
指定された webhook の URL に対してチャレンジレスポンスチェック (CRC) を実行します	PUT account_activity/webhooks/:webhook_id	✓
ユーザーのアカウントイベントをアプリケーションに購読登録します	POST account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
現在アクティブなサブスクリプション数を返します	GET account_activity/subscriptions/count		✓
webhook 設定がユーザーのイベントを購読しているかどうかを確認します	GET account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
現在アクティブなサブスクリプションのリストを返します	GET account_activity/webhooks/:webhook_id/subscriptions/all/list		✓
webhook を削除します	DELETE account_activity/webhooks/:webhook_id	✓
[DEPRECATED] 指定されたユーザーコンテキストおよびアプリケーションに対するサブスクリプションを無効化します	DELETE account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
アプリケーション専用 OAuth を使用してサブスクリプションを無効化します	DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json		✓
アクティビティを webhook に再配信します	POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json		✓

*_ 認証には、サブスクリプションを行うユーザーのアクセストークンが必要です。 _ OAuth 1.0a のユーザーコンテキスト認証を必要とするエンドポイントでは、リクエストを認証するために次のクレデンシャルを指定する必要があります。

Consumer Keys (API Key と Secret)
Access Tokens (Access Token と Secret)

次の 3 つのエンドポイントの場合、アプリケーションのコンテキスト内で書き込み操作を実行します (X ユーザーは関与しません) 。そのため、提供する必要がある Access Token は、あなたの開発者 App に属するものです。これらは、開発者コンソール内の App の「Keys and tokens」タブから直接生成できます。

POST account_activity/webhooks: 指定されたアプリケーションコンテキストに対して新しい Webhook URL を登録します
PUT account_activity/webhooks/:webhook_id: 指定された Webhook の URL に対して CRC (Challenge Response Check) をトリガーします
DELETE account_activity/webhooks/:webhook_id: Webhook を削除します

一方、次の 3 つのエンドポイントでは、X ユーザー (たとえば Direct Messages) の保護されたデータへ、アプリケーションがユーザーに代わってアクセスできるようにするリクエストを行います。そのため、対象となるサブスクライブユーザーに属する Access Token を指定する必要があります。必要な Access Token は 3-legged OAuth フローを使用して取得できます (OAuth 1.0a: how to obtain a user’s Access Tokens を参照) 。これらのエンドポイントには、上記の表内でアスタリスク (*) が付いています。

POST account_activity/webhooks/:webhook_id/subscriptions/all: アプリケーションをユーザーのアカウントイベントにサブスクライブさせます
GET account_activity/webhooks/:webhook_id/subscriptions/all: Webhook の設定がユーザーのイベントをサブスクライブしているかどうかを確認します
DELETE account_activity/webhooks/:webhook_id/subscriptions/all: 指定されたユーザーコンテキストとアプリケーションのサブスクリプションを無効化します [DEPRECATED]

ご注意ください: 開発者 App が「Read, Write, and Direct Messages」に有効になっていることを確認してください。この設定は、開発者アカウントの Projects & Apps セクション内で、対象の開発者 App の「App permissions」から変更できます。権限設定を変更した後は、App クレデンシャルを再生成する必要があります。

Account Activity API で利用可能なすべてのエンドポイントの一覧 (説明および認証の実装例を含む cURL リクエスト例を含む) は、APIリファレンス文書に記載されています。詳細については、Enterprise Account Activity API を使い始める際に役立つ XDev の sample web app and helper scripts を参照してください。

再試行

Enterprise Account Activity API のエンタープライズティアの利点の 1 つは、webhook イベントに対する再試行メカニズムが提供されることです。success を示す HTTP 200 レスポンスコードが受信されない場合、X サーバーは再試行メカニズムを開始し、5 分間に最大 3 回まで webhook イベントを再送信します。この webhook イベント再試行サービスにより、ネットワーク障害が発生した場合や、クライアント側のサービス中断やデプロイ時にも、信頼性の向上とイベントの復旧に役立ちます。

リトライとは何ですか？

Account Activity API には、クライアントの Web アプリがアカウントアクティビティの webhook イベントに対して「成功」を示す 200 レスポンスを返さない場合に、リトライを行う機能があります。クライアント側がイベントを正常に受信したことを確認しない場合、X はそのイベントが受信されなかったものとみなします。非 200 レスポンスを受信した場合、3 秒以内にレスポンスが受信できない場合、またはまったくレスポンスを受信しない場合、リクエストを再送し、そのリクエストを 3 秒間オープンな状態にして待機します。これは、X があなたの webhook URL に送信しようとしているアクティビティに対して応答するために、2 回の試行で合計およそ 5 秒の猶予があることを意味します。サーバーが応答しない、または一時的なエラーを返す場合、5 分間にわたってリトライを継続します。検証を確認するためのリトライ試行は合計 3 回行われます。これにより冗長性と安全策が確保され、すべての webhook イベントを確実に受信できるようになります。リトライが発生しているサブスクリプションでは、購読しているすべてのユーザーに対する任意／すべてのアクティビティについて、リトライされたイベントを受け取ることになります。これら 8 回の試行のいずれにおいても検証を確認できなかった場合、そのアクティビティは Account Activity API 経由では利用できなくなります。

リトライタイムライン

Account Activity API は、200 レスポンスが受信されるまで、最大 5 分間のあいだに最大 3 回までリトライを行います。詳しくは以下の表を参照してください。約 5 分を過ぎると、そのアクティビティは Account Activity API を通じて再送できません。取り逃したデータを収集するには、他の X のエンドポイントを使用する必要があります。たとえば、search APIs を使用して、該当する投稿、リツイート、引用ツイート、メンション、返信を取得できます。取り逃したダイレクトメッセージは、このエンドポイントで取得できます。

再試行タイムライン


アクティビティが作成され、Account Activity API から webhook URL へ POST リクエストが送信されますが、3 秒でタイムアウトします。
直前のタイムアウト終了から 3 秒待機し、その後 Account Activity API から webhook URL へ再度 POST リクエストが送信され、3 秒でタイムアウトします。
直前のタイムアウト終了から 27 秒待機し、その後 Account Activity API から webhook URL へ再度 POST リクエストが送信され、3 秒でタイムアウトします。
直前のタイムアウト終了から 242 秒待機し、その後 Account Activity API から webhook URL へ再度 POST リクエストが送信され、3 秒でタイムアウトします。
この後、Account Activity API は POST の試行を停止します。Client は他の X エンドポイントを使用してデータを復旧する必要があります。

アカウントアクティビティのデータオブジェクト構造

Object	Details
for_user_id	イベントが関連するユーザーサブスクリプションを識別します。
is_blocked_by	(条件付き) 別のユーザーが、あなたがサブスクライブしているユーザーにメンションした場合にのみ表示されます。ポストへのメンションイベントで true の場合にのみ含まれます。
source	アクティビティを実行しているユーザーです。たとえば、フォロー、ブロック、ミュートを行っているユーザーが source ユーザーです。
target	アクティビティの対象となるユーザーです。たとえば、フォローされる、ブロックされる、ミュートされるユーザーが target ユーザーです。

利用可能なアクティビティ

Message Type	Details
tweet_create_events	サブスクリプションユーザーによって、またはサブスクリプションユーザーに対して、次のいずれかのアクションが行われたときのポストステータスのペイロードです：ポスト、リツイート、返信、@メンション、QuoteTweets、Quote Tweet のリツイート。
favorite_events	ユーザーと対象ユーザーを含む、いいねイベントステータスです。
follow_events	ユーザーと対象ユーザーを含む、フォローイベントです。
unfollow_events	ユーザーと対象ユーザーを含む、フォロー解除イベントです。
block_events	ユーザーと対象ユーザーを含む、ブロックイベントです。
unblock_events	ユーザーと対象ユーザーを含む、ブロック解除イベントです。
mute_events	ユーザーと対象ユーザーを含む、ミュートイベントです。
unmute_events	ユーザーと対象ユーザーを含む、ミュート解除イベントです。
user_event	ユーザーがアプリケーションの認可を取り消し、そのサブスクリプションが自動的に削除されたときに送信される失効イベントです。
direct_message_events	ダイレクトメッセージが送信または受信されたときの、ユーザーと対象ユーザーを含むダイレクトメッセージステータスです。
direct_message_indicate_typing_events	ユーザーと対象ユーザーを含む、ダイレクトメッセージの入力中イベントです。
direct_message_mark_read_events	ユーザーと対象ユーザーを含む、ダイレクトメッセージの既読イベントです。
tweet_delete_events	コンプライアンスを容易に維持できるようにするための、削除された投稿の通知です。

ペイロード例 上記の表で説明した各アカウントアクティビティイベントについて、以下のペイロード例を参照してください。

tweet_create_events (投稿、リツイート、返信、引用ツイート)

{
	"for_user_id": "2244994945",
	"tweet_create_events": [
	  {
		<Tweet Object>
	  }
	]
}

tweet_create_events (@メンション)

{
	"for_user_id": "2244994945",
	"user_has_blocked": "false",
	"tweet_create_events": [
	  {
		<Tweet Object>
	  }
	]
}

favorite_events

{
	"for_user_id": "2244994945",
	"favorite_events": [{
		"id": "a7ba59eab0bfcba386f7acedac279542",
		"created_at": "Mon Mar 26 16:33:26 +0000 2018",
		"timestamp_ms": 1522082006140,
		"favorited_status": {
			<Tweet Object>
		},
		"user": {
			<User Object>
		}
	}]
}

follow_events

{
	"for_user_id": "2244994945",
	"follow_events": [{
			"type": "follow",
			"created_timestamp": "1517588749178",
			"target": {
				<User Object >
			},
			"source": {
				< User Object >
			}
		]
	}
}

unfollow_events

{
	"for_user_id": "2244994945",
	"follow_events": [{
			"type": "unfollow",
			"created_timestamp": "1517588749178",
			"target": {
				<User Object >
			},
			"source": {
				< User Object >
			}
		]
	}
}

block_events

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "block",
		"created_timestamp": "1518127020304",
		"source": {
			<User Object>
		},
		"target": {
			<User Object>
		}
	}]
}

unblock_events

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "unblock",
		"created_timestamp": "1518127020304",
		"source": {
			<User Object>
		},
		"target": {
			<User Object>
		}
	}]
}

mute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "mute",
		  	"created_timestamp": "1518127020304",
			"source": {
				<User Object>
			},
			"target": {
				<User Object>
			}
		}
	]
}

unmute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "unmute",
		  	"created_timestamp": "1518127020304",
			"source": {
				<User Object>
			},
			"target": {
				<User Object>
			}
		}
	]
}

user_event

{
	"user_event": {
		"revoke": {
			"date_time": "2018-05-24T09:48:12+00:00",
			"target": {
				"app_id": "13090192"
			},
			"source": {
				"user_id": "63046977"
			}
		}
	}
}

direct_message_events

{
  	"for_user_id": "4337869213",
	"direct_message_events": [{
		"type": "message_create",
		"id": "954491830116155396",
		"created_timestamp": "1516403560557",
		"message_create": {
			"target": {
				"recipient_id": "4337869213"
			},
			"sender_id": "3001969357",
			"source_app_id": "13090192",
			"message_data": {
				"text": "Hello World!",
				"entities": {
					"hashtags": [],
					"symbols": [],
					"user_mentions": [],
					"urls": []
				}
			}
		}
	}],
	"apps": {
		"13090192": {
			"id": "13090192",
			"name": "FuriousCamperTestApp1",
			"url": "https://x.com/furiouscamper"
		},
		"users": {},
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE opinions-are-my-own",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 22,
			"friends_count": 45,
			"statuses_count": 494,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		},
		"4337869213": {
			"id": "4337869213",
			"created_timestamp": "1448312972328",
			"name": "Harrison Test",
			"screen_name": "Harris_0ff",
			"location": "Burlington, MA",
			"protected": false,
			"verified": false,
			"followers_count": 8,
			"friends_count": 8,
			"profile_image_url": "null",
			"statuses_count": 240,
			"profile_image_url_https": "https://abs.twimg.com/sticky/default_profile_images/default_profile_normal.png"
		}
	}
}

direct_message_indicate_typing_events

{
	"for_user_id": "4337869213",
	"direct_message_indicate_typing_events": [{
		"created_timestamp": "1518127183443",
		"sender_id": "3284025577",
		"target": {
			"recipient_id": "3001969357"
		}
	}],
	"users": {
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE opinions-are-my-own",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 23,
			"friends_count": 47,
			"statuses_count": 509,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		},
		"3284025577": {
			"id": "3284025577",
			"created_timestamp": "1437281176085",
			"name": "Bogus Bogart",
			"screen_name": "bogusbogart",
			"protected": true,
			"verified": false,
			"followers_count": 1,
			"friends_count": 4,
			"statuses_count": 35,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/763383202857779200/ndvZ96mE_normal.jpg"
		}
	}
}

direct_message_mark_read_events

{
	"for_user_id": "4337869213",
	"direct_message_mark_read_events": [{
		"created_timestamp": "1518452444662",
		"sender_id": "199566737",
		"target": {
			"recipient_id": "3001969357"
		},
		"last_read_event_id": "963085315333238788"
	}],
	"users": {
		"199566737": {
			"id": "199566737",
			"created_timestamp": "1286429788000",
			"name": "Le Braat",
			"screen_name": "LeBraat",
			"location": "Denver, CO",
			"description": "data by day @X, design by dusk",
			"protected": false,
			"verified": false,
			"followers_count": 299,
			"friends_count": 336,
			"statuses_count": 752,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/936652894371119105/YHEozVAg_normal.jpg"
		},
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE opinions-are-my-own",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 23,
			"friends_count": 48,
			"statuses_count": 510,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		}
	}
}

tweet_delete_events

{
    "for_user_id": "930524282358325248",
    "tweet_delete_events": [
{
        "status": {
            "id": "1045405559317569537",
            "user_id": "930524282358325248"
        },
        "timestamp_ms": "1432228155593"
    }
   ]
}

Account Activity Replay API

Enterprise Account Activity Replay API は、最大 5 日前までのイベントを取得できるデータリカバリツールです。webhook サーバーがイベントの受信に失敗した状況、たとえば retry window を超える切断が発生した場合や、システムを通常どおりの状態に復旧するまでに数日を要するディザスタリカバリのシナリオにおいて、データを復旧する目的で使用します。 Account Activity Replay API は、ある期間にわたって activities の取り込みに失敗したあらゆるシナリオを想定して開発されました。アクティビティは、元のリアルタイム配信で使用されていたものと同じ webhook に配信されます。本プロダクトはリカバリツールでありバックフィルツールではないため、過去に配信が試行されたイベントのみがリプレイされます。Account Activity Replay API は、サブスクリプションが作成された時刻より前の期間のイベントを配信することはできません。

Account Activity Replay API の使用

アカウントで Replay 機能が有効になっている場合、Account Activity API へのリクエストとほぼ同様の方法でリクエストを送信できます。重要な点として、どの webhook のアクティビティをリプレイしたいかを示すために、リクエストで webhook id パラメーターを指定する必要があります。言い換えると、Replay リクエストは、webhook id と application id に基づいて、開始日時から終了日時までのイベントを取得するよう Account Activity Replay API に要求するものです。 UTC 時刻で指定する必要がある点に注意してください。これらのアクティビティは、その id に関連付けられた登録済み webhook を通じて、1 秒あたり最大 2,500 件のイベントの速度で配信されます。また、1 つの webhook につき同時に実行できる Replay ジョブは 1 つだけですが、その webhook で指定された日時の期間中にアクティブだったすべてのサブスクリプションがリプレイされることも覚えておいてください。イベントは、指定した期間の最初 (最も古い) 1 分間から配信が開始され、その後は最終分が配信されるまで、 (可能な限り) 時系列順に続きます。その時点で、Replay はジョブ完了イベントを webhook に配信します。アクティビティは時系列順に配信されるため、開始時刻付近に一致する結果がほとんどない、またはまったくない場合、最初の結果が配信されるまでに時間が空く可能性があります。

制限事項

Replay は、最大で 5 日前までのアクティビティを簡単に取得するためのツールとして設計されていますが、サブスクリプションが作成された時刻より前のイベントは配信されません。たとえば、3 日前に新しいサブスクリプションを追加し、本日から過去 5 日間を対象とする Replay ジョブを実行した場合、受信できるのはこの新しいサブスクリプションが有効だった 3 日間分のデータのみです。

データの可用性と種類

Account Activity Replay API からのアクティビティは、リクエストの開始から 5 日間利用可能で、各アクティビティが作成されてからおよそ 10 分後に新しいデータが利用可能になります。from_date パラメータと to_date パラメータを使用して、この 5 日間の範囲内の任意の期間を指定してリクエストを行うことができます。Replay へのアクセス権を得る前に元々配信されていたイベントは、Replay を使ってリプレイすることはできません。たとえば、お使いのアカウントが 2019 年 6 月 1 日 3:30PM UTC に Account Activity Replay API へのアクセスが有効化された場合、その日時より前のイベントを Replay を使って取得することはできません。 Account Activity Replay APIリファレンスを参照してください。

移行の概要

Site Streams、User Streams、および Account Activity API - DM Only の標準ベータ版プロダクトは 2018 年に提供終了しました。これらのプロダクトを利用していた場合は、必ず Account Activity API のプレミアム版またはエンタープライズ版へ移行してください。レガシーの Direct Message エンドポイントも提供終了しました。これらのエンドポイントを利用していた場合は、新しい DM エンドポイント、または Account Activity API のプレミアム版もしくはエンタープライズ版のいずれかに必ず移行してください。 詳しくはこのアナウンスを参照してください。 これらの変更により影響を受けるエンドポイントは次のとおりです。

User Streams
Site Streams
GET direct_messages
GET direct_messages/sent
GET direct_messages/show
POST direct_messages/new
POST direct_messages/destroy

これらと同様のアクセス手段を提供し、Direct Message については追加機能も備えた新しいエンドポイントとサービスが用意されています。

Account Activity API の enterprise および premium
GET direct_messages/events/list
GET direct_messages/events/show
POST direct_messages/events/new
POST direct_messages/events/destroy

これらの新しいエンドポイントやサービスへのスムーズな移行を支援するため、以下の 2 つの移行ガイドを用意しています。

User Streams および Site Streams から新しい Webhook ベースのサービスへ移行する方向けの Account Activity API 移行ガイド
Direct Message の REST エンドポイント間で移行する方向けの Direct Message 移行ガイド

さらに、Account Activity API とその始め方について解説した一連の動画も用意しています。最後に、理解を深め、すぐに使い始められるようにするためのコードサンプルも提供しています。

Account Activity Dashboard は、Account Activity API の利用を開始するためのヘルパースクリプトを備えたサンプルの Node.js Web アプリです。
SnowBot は、Account Activity API と REST の Direct Message エンドポイントを利用するサンプルチャットボットです。Ruby で実装され、Sinatra Web アプリフレームワークを使用し、Heroku にデプロイされています。

移行ガイド: User Streams/Site Streams から Account Activity API への移行

2018 年 8 月 23 日をもって、Site Streams と User Streams は廃止されました。必ず Account Activity API へ移行してください。 詳細については、このお知らせを参照してください。 このガイドは、従来の User Streams および Site Streams API から、その後継である Account Activity API への移行を支援することを目的としています。以下では、変更点の概要、新機能の一覧、および移行を進めるうえで役立つ主な相違点や考慮事項を説明します。基本的な DM エンドポイントからの移行方法については、ダイレクトメッセージ移行ガイドを参照してください。

変更点の概要

Account Activity API は、User Streams や Site Streams のようなストリーミング接続ではなく、Webhook を通じて、認証およびサブスクライブ済みアカウントのイベントを配信します。

非推奨 API

GET user GET site (制御ストリームを含む: GET site/c/:stream_id, GET site/c/:stream_id/info.json, GET site/c/:stream_id/friends/ids.json, POST site/c/:stream_id/add_user.json, POST /site/c/:stream_id/remove_user.json)

後継 API

Enterprise Account Activity API - すべてのアクティビティ

違いと移行時の考慮事項

API 形式: 新しい Account Activity API は、User Streams や Site Streams とは動作が異なります。webhooks でデータを受信できるよう、Web アプリを変更する必要があります。webhooks の詳細はこちらをご覧ください。 利用可能なデータ: もう 1 つの大きな違いは、配信されるデータの内容です。X は、あなたが X 上でフォローしているユーザー (いわゆるホームタイムライン) からのイベントを今後は送信しません。これは意図的な変更であり、今後変更する予定はありません。 信頼性: ストリーミングと異なり、webhooks では配信確認が可能であり、webhook URL に到達しなかった POST されたアクティビティを再試行するオプションも提供します。これにより、短時間の切断やダウンタイムが発生した場合でも、App が該当するすべてのアクティビティを確実に受信できる可能性が高まります。

新機能

Account Activity API では多くの新機能が提供されていますが、特に大きな変更点は、データがストリーミングではなく Webhook 経由で配信されるようになったことです。Webhook にはストリーミングと比べて多くの利点がありますが、その中でも最も大きいのは速度と信頼性です。API は、データが利用可能になり次第、JSON イベントとして送信するため、アクティブな接続を維持したり、エンドポイントをポーリングしたりする必要がなくなります。これにより冗長化機能の必要性が抑えられ、全体的な効率が向上します。Webhook の詳細については、技術ドキュメントを参照してください。

ユーザーサブスクリプションの管理

Account Activity API では、1 つの登録済み webhook に対して複数のサブスクリプションを設定できます。これにより、Site Streams のアーキテクチャと同様に、複数のユーザーサブスクリプションのアクティビティを、webhooks を使って同じ場所に配信できます。これは、サブスクリプション数の上限管理の観点から、サブスクリプションを webhook 接続とは独立して追跡できることも意味します。また、これにより、1 つまたは少数のサブスクリプションから、1 つの webhook あたり数千のサブスクリプションへとスケールさせることができます。

移行手順

以下の手順に従って、Site Streams API から Account Activity API へ簡単に移行できます

ステップ 1: パッケージを決定する 現在 User Streams または Site Streams をどのように運用しているかに応じて、Account Activity API の enterprise 版か premium 版のいずれかへの移行を検討する必要があります。現在サポートしているアプリケーション数または認可済みユーザー数を考慮し、必要なボリュームと信頼性に応じて適切にスケールしてください。どのパッケージがニーズに最も適しているかを決定する際には、次の点を考慮してください。

必要な webhook の数
アプリケーションで管理している現在/将来想定の購読/認可済みユーザー数
現在の X クライアントアプリケーション数
X から希望するサポートレベル (フォーラムサポートか、マネージド enterprise レベルの 1:1 サポートか)
各パッケージの価格

ステップ 2: 開発者コンソールで X App のセットアップを確認する 現在 User Streams または Site Streams に使用している X app は、開発者コンソール上で所有ユーザーに紐づいて一覧表示されています。この X app は、同じアプリケーションの認可済みユーザーを保持するために Account Activity API でも利用できます。新しい App を作成し、必要に応じてユーザーに対してこの新しい App への再認可を行ってもかまいません。企業を代表して新しい App を作成する場合は、企業の X の @handle アカウントで App を作成することを推奨します。

X app ページの permissions タブで「Read, Write and Access direct messages」を有効にします。 *これらの設定変更は遡及的には適用されず、既に認可済みのユーザーは認可時点の設定を維持することに注意してください。ユーザーがまだ read、write、direct message アクセスを付与していない場合は、そのユーザーにアプリケーションを再認可してもらう必要があります。
X Sign-in や、X API におけるユーザーコンテキストの仕組みに不慣れな場合は、Obtaining Access Tokens を確認してください。
「Keys and Tokens」タブの下部で、X app のオーナー用のアクセストークンを生成します。同じタブで、Consumer Key、Consumer Secret、Access Token、Access Token Secret を控えておいてください。API を利用する際に必要になります。
application-only API メソッド用に、Consumer Key と Consumer Secret を使用してベアラートークンを生成します。

ステップ 3: Webhook のセットアップと設定

イベントを受信するための webhook として使用するエンドポイントを備えた Web アプリを作成します (例: https://your_domain.com/webhook/twitter または https://webhooks.your_domain.com) 。
webhook を作成する際に、Consumer Key、Consumer Secret、Access Token、Access Token Secret を使用します。エンドポイントは、response_token を含む JSON レスポンスを返す必要があり、response_token は crc_token と App の Consumer Secret から生成される base64 エンコードされた HMAC SHA-256 ハッシュでなければなりません。
Securing Webhooks ドキュメントを確認し、特に Challenge Response Check (CRC) の要件をよく確認してください。
webhook が着信イベント用の POST リクエストと、CRC 用の GET リクエストをサポートしていることを確認します。
webhook が低レイテンシであることを確認します (POST リクエストへの応答が 3 秒未満) 。

ステップ 4: Webhook 設定を検証する

Webhook API は、次の 2 つの方法で webhook を保護します。

- Challenge Response Check を要求し、webhook の所有者が Web アプリの所有者であることを検証します。 - 各 POST リクエストに署名ヘッダーを付与し、Web アプリ側で送信元を検証できるようにします。

あなたが Web アプリと webhook URL の両方の所有者であることを検証するために、X は Challenge Response Check (CRC) を実行します。これは cyclic redundancy check とは異なることに注意してください。
crc_token という名前のパラメータを含む GET リクエストが webhook URL に送信されます。エンドポイントは、crc_token と App の Consumer Secret から生成された base64 エンコード済み HMAC SHA-256 ハッシュである response_token を含む JSON レスポンスを返さなければなりません。
crc_token は、受信する各 CRC リクエストごとに変更されると想定してください。crc_token は計算時のメッセージとして使用し、Consumer Secret をキーとして使用します。
応答が無効な場合、登録された webhook へのイベント送信は停止されます。

ステップ 5: 各 User Stream または Site Streams の認可済みユーザーに対してサブスクリプションを作成する User Streams から Account Activity API へ移行する場合:

User Streams 上で、現在のユーザーサブスクリプションの一覧を取得します
次のリクエストを使用して、新しい Account Activity API のサブスクリプションを設定します: POST account_activity/all/:env_name/subscriptions
次のリクエストを使用して、Account Activity API のサブスクリプションを確認します: _GET account_activity/all/:env_name/subscriptions/list _

Site Streams から Account Activity API への移行: (コントロールストリームを使用)

次のリクエストを使用して、Site Streams 上で現在のサブスクリプションの一覧を取得します: GET /1.1/site/c/:stream_id/info.json
次のリクエストを使用して、新しい Account Activity API のサブスクリプションを設定します: POST account_activity/all/:env_name/subscriptions
次のリクエストを使用して、Account Activity API のサブスクリプションを確認します: _GET account_activity/all/:env_name/subscriptions/list _

Webhook の登録とサブスクリプションの作成 (Site Streams または User Streams からの移行ではない場合)

POST webhooks を使用して App に webhook URL を登録し、webhook_id を受け取ります。
返された webhook_id を使用して、POST webhooks/:webhook_id/subscriptions/all でユーザーサブスクリプションを追加します。

Account Activity ダッシュボード (Account Activity API サンプルアプリ)

Account Activity API のテストを少しでも早く行えるよう、サンプルアプリを用意しました。

Account Activity Dashboard サンプルアプリケーションをこちらからダウンロードします (Node.js を使用します)
README の手順に従ってアプリをインストールし、起動します
アプリケーションを起動したら、UI から webhook を簡単に設定し、新しいサブスクリプションを作成できます

利用可能なアクティビティ

メッセージタイプ	詳細
tweet_create_events	サブスクリプションユーザーが行う、またはサブスクリプションユーザーに対して行われる次のいずれかのアクション時のポストステータスのペイロード：投稿、リツイート、返信、@メンション、引用ツイート
favorite_events	ユーザーと対象ユーザーを含む「いいね」 (Favorite) イベントのステータス。
follow_events	ユーザーと対象ユーザーを含むフォローイベント。
block_events	ユーザーと対象ユーザーを含むブロックイベント。
mute_events	ユーザーと対象ユーザーを含むミュートイベント。
direct_message_events	ユーザーと対象ユーザーを含むダイレクトメッセージのステータス。
direct_message_indicate_typing_events	ユーザーと対象ユーザーを含むダイレクトメッセージの入力中イベント。
direct_message_mark_read_events	ユーザーと対象ユーザーを含むダイレクトメッセージの既読イベント。

廃止されたストリーミングメッセージ種別


空行	空行は User Streams および Site Streams ではキープアライブメッセージとして使われていましたが、Account Activity API では今後配信されません。
制限通知	制限通知は特定の webhook 宛てには今後送信されません。代わりに、利用可能なハンドルの現在の使用状況を取得するために API を呼び出すことができます。これは将来的に開発者コンソールにも表示される予定です。
切断メッセージ	webhook はアクティブな接続に依存しないため、切断通知は今後不要になります。
停滞警告	webhook は大量の受信メッセージを処理できるアクティブな接続に依存しないため、停滞警告は今後不要になります。
フレンドリスト	フレンドリストは今後事前に送信されることはありません。代わりに、この情報を取得するための REST エンドポイントが提供されます。

非推奨のイベント種別


説明	イベント名	ソース	ターゲット	ターゲットオブジェクト
ユーザーがポストを削除する	delete	現在のユーザー	現在のユーザー	ポスト
フォローしているユーザーがポストを削除する	delete	フォローしているユーザー	フォローしているユーザー	ポスト
ユーザーがポストのいいねを取り消す	unfavorite	現在のユーザー	ポストの作成者	ポスト
ユーザーのポストのいいねが取り消される	unfavorite	いいねを取り消したユーザー	現在のユーザー	ポスト
ユーザーが誰かのフォローを解除する	unfollow	現在のユーザー	フォローしていたユーザー	Null
ユーザーがリストを作成する	list_created	現在のユーザー	現在のユーザー	リスト
ユーザーがリストを削除する	list_destroyed	現在のユーザー	現在のユーザー	リスト
ユーザーがリストを編集する	list_updated	現在のユーザー	現在のユーザー	リスト
ユーザーが誰かをリストに追加する	list_member_added	現在のユーザー	追加されたユーザー	リスト
ユーザーがリストに追加される	list_member_added	追加したユーザー	現在のユーザー	リスト
ユーザーが誰かをリストから削除する	list_member_removed	現在のユーザー	削除されたユーザー	リスト
ユーザーがリストから削除される	list_member_removed	削除したユーザー	現在のユーザー	リスト
ユーザーがリストを購読する	list_user_subscribed	現在のユーザー	リストの所有者	リスト
ユーザーのリストが購読される	list_user_subscribed	購読したユーザー	現在のユーザー	リスト
ユーザーがリストの購読を解除する	list_user_unsubscribed	現在のユーザー	リストの所有者	リスト
ユーザーのリストの購読が解除される	list_user_unsubscribed	購読を解除したユーザー	現在のユーザー	リスト
ユーザーがプロフィールを更新する	user_update	現在のユーザー	現在のユーザー	Null
ユーザーが保護状態を更新する	user_update	現在のユーザー	現在のユーザー	Null

ダイレクトメッセージ移行ガイド

2018 年 9 月 17 日に従来のダイレクトメッセージ用エンドポイントを廃止しました。これらのエンドポイントを利用していた場合は、新しいダイレクトメッセージ用エンドポイントまたは Account Activity API へ必ず移行してください。 詳しくは、このお知らせをご確認ください。 このガイドは、従来のダイレクトメッセージ REST API から、ベータ版を卒業した強化版 API へ移行する際の支援を目的としています。以下では、変更点の概要、新機能の一覧、移行に役立つ主な相違点と考慮事項を説明します。新しいダイレクトメッセージ用エンドポイントは、すべての開発者にご利用いただけます。User Streams または Site Streams からの移行については、Account Activity API への移行ガイドを参照してください。

変更点の概要
新機能
ダイレクトメッセージの送信
ダイレクトメッセージの受信
ダイレクトメッセージの削除

変更概要

以下のDMエンドポイントをまだ使用している場合は、新しいエンドポイントへ移行する必要があります。

非推奨エンドポイント	移行先エンドポイント
POST direct_messages/new	POST direct_messages/events/new
GET direct_messages/show	GET direct_messages/events/show
GET direct_messages	GET direct_messages/events/list
GET direct_messages/sent	GET direct_messages/events/list
POST direct_messages/destroy	DELETE direct_messages/events/destroy

新機能

新しい Direct Message API エンドポイントは、さまざまな新機能に対応し、既存のダイレクトメッセージへのアクセスを改善します。新機能には次のようなものがあります。

メディア (画像、GIF、動画) の添付に対応。
あらかじめ定義された選択肢リストを使って、ユーザーに構造化された返信を促す機能。
過去 30 日分のダイレクトメッセージへのアクセス。

新しい Direct Message 機能の一覧およびその他の新しい API エンドポイントについては、技術ドキュメントを参照してください。

違いと移行時の考慮事項

新しい API エンドポイントは、従来のエンドポイントとは大きく動作が異なります。単にエンドポイントの URL を更新するだけでは、アプリケーションでエラーが発生します。移行に向けてアプリケーションを更新する際は、次の点を考慮してください。

新しいダイレクトメッセージオブジェクト

最初に気づくのは、ダイレクトメッセージの新しいオブジェクト構造でしょう。Quick Replies や Attachments などの新しい機能をサポートするために、この新しい Message Create オブジェクト構造が導入されています。この新しいオブジェクトには、よりコンパクトなユーザーオブジェクトも含まれます。アプリケーションは、この新しいオブジェクト構造を考慮して、パース処理や、場合によってはデータモデルやストレージを更新する必要があります。各プロパティの説明については、Message Create オブジェクトに関する詳細なドキュメントを参照してください。 Message Create オブジェクトの例

{
      "type": "message_create",
      "id": "1234858592",
      "created_timestamp": "1392078023603",
      "initiated_via": {
        "tweet_id": "123456",
        "welcome_message_id": "456789"
      },
      "message_create": {
        "target": {
          "recipient_id": "1234858592"
        },
        "sender_id": "3805104374",
        "source_app_id": "268278",
        "message_data": {
          "text": "青い鳥",
          "entities": {
            "hashtags": [],
            "symbols": [],
            "urls": [],
            "user_mentions": [],
          },
          "quick_reply_response": {
            "type": "options",
            "metadata": "external_id_2"
          },
          "attachment": {
            "type": "media",
            "media": {
             ...
            }
          }
        }
      }

概要

ダイレクトメッセージ (Direct Message) オブジェクト構造が完全に刷新されました。
user オブジェクトが簡略化されました。
新しい情報が追加されました (クイック返信の応答、添付ファイルなど) 。

ダイレクトメッセージの送信

POST direct_messages/events/new は、ダイレクトメッセージ送信のための代替エンドポイントです。主な違いは、このエンドポイントではすべての情報が個々の POST パラメータではなく、POST リクエストボディ内の JSON として送信される点です。 Twurl リクエスト例

twurl -A 'Content-type: application/json' -X POST /1.1/direct\_messages/events/new.json -d '{"event": {"type": "message\_create", "message\_create": {"target": {"recipient\_id": "4534871"}, "message_data": {"text": "Hello World!"}}}}'

上記のリクエストでは、Content-Type ヘッダーが application/x-www-form-urlencoded ではなく application/json に設定されている点に注意してください。さらに、OAuth 1.0a の署名を生成する場合、その署名の生成には JSON 本文が含まれないことにも注意してください。ほとんどの OAuth ライブラリは既にこの点を考慮しています。twurl を使用している場合は、バージョン 0.9.3 以上を使用していることを確認してください。

概要

メッセージは JSON の POST リクエストボディ内で定義されます。
Content-Type ヘッダーは application/json に設定する必要があります。
JSON ボディは OAuth 署名生成の対象には含まれません。

ダイレクトメッセージの取得

過去のダイレクトメッセージは、単一の API エンドポイントで取得できるようになりました: GET direct_messages/events/list。この新しいエンドポイントの大きな違いは、送信メッセージと受信メッセージの両方を、新しいものから古いものへ並べて返す点です。これにより、会話を再構築しやすくなります。ただし、送信メッセージまたは受信メッセージのみを取得したい場合は、sender_id プロパティを参照してレスポンスを後処理する必要があります。ページネーションは、ダイレクトメッセージの ID ではなく、カーソル値に基づく方式になりました。各レスポンスには cursor プロパティが返されます。GET direct_messages/events/list は、過去 30 日以内に存在するメッセージ数にかかわらず、最大で過去 30 日分のメッセージを返します。cursor が返されない場合は、それ以上返せるメッセージがないことを意味します。GET direct_messages/events/show による個別のダイレクトメッセージへのアクセス方法は従来どおりですが、返されるダイレクトメッセージオブジェクトの構造は、前述のとおり変更されています。最後に、ダイレクトメッセージへのリアルタイムアクセスは、Account Activity API を用いた webhook によって行うようになりました。User Streams や Site Streams からの移行に関するガイダンスについては、Account Activity API への移行ガイドを参照してください。

概要

送信メッセージと受信メッセージが同じエンドポイントで返されるようになりました。
最大30日分のメッセージが返されます。
カーソルベースのページネーションに対応しました。
Webhook を通じてダイレクトメッセージにリアルタイムでアクセスできます。

ダイレクトメッセージの削除

ダイレクトメッセージは、DELETE direct_messages/events/destroy を使用して削除できるようになりました。インターフェースはほぼ同じで、削除するメッセージの ID が必要です。主な違いは、このエンドポイントでは POST リクエストではなく DELETE リクエストが必要になった点です。削除されたダイレクトメッセージが公式 X クライアントにどのように反映されるかは、従来どおりです。ダイレクトメッセージは、指定されたユーザーコンテキストのユーザーのインターフェースからのみ削除されます。会話の他の参加者は、そのダイレクトメッセージに引き続きアクセスできます。

概要

ダイレクトメッセージを削除するには ID が必要です。
新しいエンドポイントでは DELETE リクエストが必要です。
削除されたダイレクトメッセージが公式 X クライアントにどのように反映されるかは、これまでと変わりません。

**新しいダイレクトメッセージエンドポイントへの移行について質問がありますか？
**質問は開発者コミュニティフォーラム (devcommunity.com) に投稿してください。

よくある質問

一般

Account Activity API を利用する利点は何ですか？ Account Activity API は webhook を使用します。つまり、ストリーミング API と異なり、こちらから情報を送信するためにオープンな接続を維持しておく必要がありません。Webhook は REST API とも異なり、必要なデータを取得するために 15 分ごとに何百回もポーリングする必要もありません。イベント発生と同時にデータを配信できるため、ユーザーとアプリケーション間のやり取りをより効率的に行えます。 Account Activity API には、次のような多くの利点があります。

速度: X のスピードでデータを配信します。
シンプルさ: アカウントのすべてのイベントを、単一の webhook 接続を通じて配信します。API で配信されるアクティビティには、投稿、@メンション、返信、Retweet、Quote Tweet、Quote Tweet の Retweet、いいね、送信された Direct Message、受信した Direct Message、フォロー、ブロック、ミュートが含まれます。
スケール: レート制限やイベント数の上限に縛られることなく、管理対象アカウントのすべてのアクティビティを受信できます。

Account Activity API は、プレミアムサンドボックス、プレミアム有料版、およびエンタープライズ版として提供されており、責任関連機能のためにより多くのアカウントが必要になった場合や、追加機能が必要になった場合でも、ニーズに応じてスケールできます。利用を開始するには、GitHub からサンプルのコードスニペットをダウンロードしてください。 自分に最適なプロダクトティアを見分けるにはどうすればよいですか？ プレミアムオプションとエンタープライズオプションの違いについて詳しく知るには、Account Activity API Overview ページをお読みください。 プレミアム環境とエンタープライズ webhook の違いは何ですか？ 違いはありません。各プレミアム環境には、それぞれ独自の webhook_id が付与されます。 Account Activity API 用に開発／ステージング／本番環境が必要です。これは可能ですか？ はい。Account Activity API の有料階層 (有料プレミアムおよびエンタープライズ) では、複数の webhook URL を登録し、各 URL ごとに API メソッドを通じて購読を個別に管理できます。さらに、複数のクライアント App を allowlist に追加して、現在認可されているユーザーの認可状態を維持できます。 Account Activity API のセットアップ方法について、ステップバイステップのガイドはありますか？ あります。

これから始める場合は、Getting started with webhooks ガイドを参照することをおすすめします
X Dev 提供のスクリプトもあわせてご利用ください:
- Account Activity API dashboard: webhook イベントを表示する Node.js のウェブアプリケーションです。
- SnowBot chatbot: Account Activity API および Direct Message API 上に構築された Ruby のウェブアプリケーションです。このコードベースには、Account Activity API の webhook セットアップを支援するスクリプトが含まれています。

システムが一定時間ダウンした場合、データを復旧する方法はありますか？ Account Activity API の有料階層 (有料プレミアムおよびエンタープライズ) では、当社システムが 4 時間の期間内に複数回、アクティビティの送信を再試行します。その 4 時間内にあなたのシステムが応答しない場合、そのアクティビティは失われ、7 日以内のデータを復旧するには他の REST エンドポイントを使用する必要があります。複数の webhook や環境を、Account Activity Replay API のような冗長化ツールとして使用し、いずれかのシステムがダウンした場合でもアクティビティを取り逃さないようにすることをおすすめします。 Account Activity API では、どの認証方式を使用する必要がありますか？ Account Activity API で必要となる認可方式は、APIリファレンスページの各メソッドに記載されています。X の認証を初めて利用する場合は、このセクションをお読みいただくことをおすすめします。 challenge-response check (CRC) とは何ですか？ Account Activity API のチャレンジレスポンスチェックは、Account Activity API のアクティビティが正しい開発者に送信されていることを保証するために導入されたセキュリティ機能です。これはまた、開発者が受信しているデータが X から送信されていることを確認する目的でも使用できます。X は、webhook URL が最後に検証された時点から 24 時間ごとに 1 回、自動的に CRC を webhook URL に送信します。システムは、検証状態を維持するために 3 秒以内に有効なレスポンスを返す必要があります。詳しくは、Securing webhooks のページをご覧ください。 webhook URL が即座に無効化されるケースはありますか？ 次のいずれかが発生した場合、webhook は即座に無効としてマークされます。

サーバーが CRC に対して誤ったトークンで応答した場合。この場合、弊社システムはアクティビティを送信するための再試行を行いません。
webhook URL に誤った証明書が設定されている場合。この場合も、弊社システムはアクティビティを送信するための再試行を行いません。
サーバーが 2XX、4XXX、5XXX 以外のレスポンスコードを返した場合。
gzip を使用すると指定しているにもかかわらず、実際には gzip を使用して送信していない場合。
gzip の使用を指定していないにもかかわらず、実際には gzip を使用してレスポンスを送信している場合。

互いにやり取りしているユーザーを購読した場合、重複したアクティビティを受け取ることはありますか？ はい。Web アプリがユーザー A とユーザー B に対して有効なサブスクリプションを持っており、ユーザー A がポスト内でユーザー B に言及した場合、登録済みの webhook には 2 件の POST アクティビティが送信されます。それぞれのアクティビティには、そのアクティビティがどのサブスクリプションに属するかを示す “for_user_id” フィールドが含まれます。 webhook へのサブスクリプションを作成する際、次のエンドポイントの /all/ 部分を他のアカウントアクティビティのデータオブジェクトに置き換えて、API が配信するアクティビティを制限することはできますか？POST https://api.x.com/1.1/account_activity/all/:env_name/subscriptions.json いいえ、これはできません。現時点では、利用可能なプロダクトは /all/ のみです。 ユーザーから Direct Messages の権限を要求せずに Account Activity API を使用する方法はありますか？ 現時点では、この API では Direct Messages アクティビティだけを「フィルタリングして除外する」方法がないため、Direct Messages の権限が必須となります。 Account Activity API のサンドボックス版はありますか？ はい、テスト用のサンドボックスオプションを提供しています。サンドボックスオプションでは、webhook は 1 つに制限され、サブスクリプションの最大数は 15 件までとなります。サンドボックスオプションの詳細については、ドキュメントを参照してください。 購読しているユーザーに言及しているポストに対する Retweets を、Account Activity API で取得することはできますか？ 残念ながら、これはこの API で配信されるアクティビティには含まれていません。この用途には、代わりに Streaming API の利用をお勧めします。 tweet_create_event で表される可能性のあるアクティビティタイプにはどのようなものがありますか？ tweet_create_event のペイロードは、次の場合に送信されます。サブスクリプション対象ユーザーが次のいずれかの操作を行った場合:

ポストを作成したとき
Retweet したとき
ポストに返信したとき

別のユーザーが次のことを行った場合:

サブスクリプションユーザーを @mentions* したとき
サブスクリプションユーザーが作成したツイートを引用したとき

*注: Account Activity API は、サブスクリプションユーザーが X から通知を受け取り、そのイベントを公開で確認できる場合にのみイベントを配信します。つまり、言及されたアカウント (@userA) が保護されたアカウント (@userB) をフォローしている場合、User A は User B から言及されたことの通知を受け取ります。User A が User B をフォローしていない (かつ User B に承認されていない) 場合、User A は通知を受け取らず、そのため @userA がサブスクリプションを持っていたとしても、tweet_create_event は AAA 経由で送信されません。 ブロックしているユーザーが、サブスクライブしているユーザーに言及した場合、どのように判別できますか？ json レスポンスのトップレベルにあるブール型フィールド user_has_blocked が “true” または “false” のいずれかに設定されているのが確認できます。このフィールドは、ポストへの言及に対してのみ公開されます。エンタープライズ 自分の App を allowlist に追加する、または既に allowlist に追加されているか確認するにはどうすればよいですか？ Enterprise API へのアクセス用に許可リスト (allowlist) に追加した X apps を管理するには、App の id (app ID) を添えてアカウントマネージャーまでご連絡ください。app ID は、開発者コンソールの “Apps” ページに移動すると確認できます。 3 つの webhook へのアクセス権がある場合、エンタープライズ利用として登録した各 App ごとに 3 つずつ webhook を使用できますか？ webhook の上限は App 単位ではなくアカウント単位で設定されています。3 つの webhook へのアクセス権があり、エンタープライズ利用として 2 つの App を登録している場合、1 つの App に 2 つ、もう一方の App に 1 つという形で利用できますが、各 App で 3 つずつ利用することはできません。 Account Activity Replay API で再配信されるイベントの種類を指定できますか？ リプレイするイベントの種類を指定することはできません。指定した日時の範囲内で配信されたすべてのイベントが再配信されます。 アプリケーションが Account Activity Replay API のイベントの取り込みに失敗した場合、再試行は行われますか？ いいえ、再試行は行われません。アプリケーションが Account Activity Replay API から送信されたイベントの取り込みに失敗した場合は、同じ期間を対象とする別の Replay ジョブを送信して、取り逃した Replay イベントの再配信を試みることができます。 部分的成功 (partial success) の完了イベントを受け取った場合、どうすればよいですか？ 受信できたイベントのタイムスタンプを控え、受信できなかったイベントに対して別の Replay ジョブをリクエストすることをお勧めします。 同時に実行できる Account Activity Replay API ジョブはいくつまでですか？ 1 つの webhook につき同時に実行できる Account Activity Replay API ジョブは 1 件のみです。 Webhook に配信されるイベントについて、Account Activity Replay API のイベントとリアルタイムの本番イベントをどのように区別できますか？ Account Activity Replay API は常に過去のイベントを配信するため、イベントのタイムスタンプに基づいてリアルタイムの本番イベントと区別できます。アプリケーションがドロップまたは取り逃したアクティビティを再配信するために、どのくらい早く Account Activity Replay API を利用し始めることができますか？アクティビティは、作成から約 10 分後に再配信が可能になります。

エラーのトラブルシューティングガイド

Code 32

このエラーは一般的に、指定しているリクエスト、ヘッダー、認可、または URL のいずれかの形式が不正であることを意味します。これは Account Activity API 固有のエラーではなく、認可エラーであり、X が適切な OAuth 設定や URL を受け取れていない状態です。

Enterprise - 使用しているコンシューマーキーとアクセストークンが、Enterprise 製品の利用のために登録されている X app に属していることを確認してください。コンシューマーキーやアクセストークンをお持ちでない場合、または X app を allowlist (許可リスト) に追加する必要がある場合は、アカウントマネージャーまでお問い合わせください。
ユーザーコンテキストで認証している場合は、oauth_nonce、oauth_signature、oauth_timestamp を含めて、リクエストを正しく認可していることを確認してください。
アクセストークンに適切な権限レベルが付与されていることを確認してください。
- app dashboard の「Keys and tokens」タブで、アクセストークンの権限レベルが「Read, write, and direct messages」になっていることを確認してください。
- トークンの権限レベルがこれより低く設定されている場合は、「Permissions」タブに移動し、アクセス権限を「Read, write, and direct messages」に変更してから、「Keys and tokens」タブでアクセストークンとシークレットを再生成してください。
URL が正しい形式で構成されていることを確認してください。
- :env_name は大文字と小文字を区別する点に注意してください。

Code 200 - Forbidden

Premium - API にリクエストを送信する前に、承認済みの開発者アカウントを持っていることを確認してください。また、リクエスト内で適切な :env_name を使用する必要があります。これは dev environments ページで設定できます。
Enterprise - アカウントマネージャーが、Account Activity API へのアクセス権を付与していることを確認してください。
URI を正しく設定していることを確認してください。リクエストで誤った URI を指定している場合、このエラーが発生する可能性があります。

コード 214 - webhook URL が要件を満たしていません。

HTTPS を使用していることを確認してください。
webhook URL が正しい形式になっているか確認してください。
webhook URL の設定方法については、Getting started with webhooks ページの Develop webhook consumer app セクションを参照してください。

Code 214 - CRC GET リクエストでレイテンシーが高い状態です。Webhook は 3 秒以内に応答する必要があります。

これは、サーバーの処理が遅いことを意味します。CRC に 3 秒以内に応答していることを確認してください。

コード 214 - CRC GET リクエスト中の 200 以外のレスポンスコード (例: 404、500 など)

サーバーがダウンしている可能性があります。サーバーが正常に稼働していることを確認してください。

コード 214 - 作成済みリソースが多すぎます。

Enterprise - すでに利用可能な webhook をすべて使い切っています。登録済みの各 App について GET webhooks エンドポイントを使用し、webhook がどこに割り当てられているかを特定してください。

Code 261 - アプリケーションは書き込み操作を実行できません。

使用している API 用の App のアクセストークンおよびアクセストークンシークレットに、適切な権限レベルが設定されていません。X apps ダッシュボードの「Keys and tokens」タブに移動し、アクセストークンおよびアクセストークンシークレットに割り当てられている権限レベルを確認してください。これが ‘Read, write and Direct Messages’ 以外に設定されている場合は、「Permission」タブで設定を変更し、新しい設定を反映させるためにアクセストークンおよびアクセストークンシークレットを再生成する必要があります。
別の可能性として、サポートされていない app-only 認証を使用して webhook を登録しようとしている場合があります。その場合は、Enterprise Account Activity API の webhook 登録に関する APIリファレンスのセクションに記載されているとおり、代わりにユーザーコンテキストで認証してください。

Account Activity API リファレンスインデックス


用途	エンタープライズ
webhook URL を登録する / webhook_id を生成する	POST webhooks
すべての webhook URL とそのステータスを返す	GET webhooks
チャレンジレスポンスチェックを手動でトリガーする	PUT webhooks/:webhook_id
アプリケーションをアカウントのイベントにサブスクライブさせる	POST webhooks/:webhook_id/subscriptions/all
現在アクティブなサブスクリプション数を返す	GET subscriptions/count
webhook がアカウントに対してサブスクライブされているか確認する	GET webhooks/:webhook_id/subscriptions/all
現在アクティブなサブスクリプションのリストを返す	GET webhooks/:webhook_id/subscriptions/all/list
webhook を削除する	DELETE webhooks/:webhook_id
3-legged OAuth を使用してサブスクリプションを無効化する (非推奨)	DELETE webhooks/:webhook_id/subscriptions/all
application-only OAuth を使用してサブスクリプションを無効化する	DELETE webhooks/:webhook_id/subscriptions/:user_id/all.json
アクティビティを webhook に再配信する	POST replay/webhooks/:webhook_id/subscriptions/all

エンタープライズアカウントアクティビティAPI

POST account_activity/webhooks

指定されたアプリケーションコンテキストに対して、新しい webhook URL を登録します。保存前に、URL は CRC リクエストによって検証されます。検証に失敗した場合は、リクエスト送信者に詳細なエラーメッセージを返します。許可される webhook の数は、課金パッケージによって決まります。

リソース URL

https://api.x.com/1.1/account_activity/webhooks.json

リソース情報


Response Format	JSON
Requires Authentication	はい (ユーザーコンテキスト：すべてのコンシューマートークンおよびアクセストークン)
Rate Limited	はい
Requests / 15-min window (user auth)	15
Support for Tweet edits	すべての Tweet オブジェクトには、その Tweet の編集履歴を示す Tweet 編集メタデータが含まれます。詳細については、「Tweet edits」の基本ページを参照してください。

パラメータ


url (必須)	コールバック用エンドポイントのエンコードされた URL。

リクエスト例

$ curl —request POST —url ‘https://api.x.com/1.1/account_activity/webhooks.json?url=https%3A%2F%2Fyour_domain.com%2Fwebhooks%2Ftwitter%2F0' —header ‘authorization: OAuth oauth_consumer_key=“CONSUMER_KEY”, oauth_nonce=“GENERATED”, oauth_signature=“GENERATED”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“GENERATED”, oauth_token=“ACCESS_TOKEN”, oauth_version=“1.0“‘

HTTPレスポンス

HTTP Code	メッセージ
200	Webhook URL が指定されたアプリケーションに登録されています
403	リクエストにエラーがあります。以下のエラーメッセージセクションを参照してください。

レスポンス例 - 成功時

_HTTP 200_

    {
      "id": "1234567890",
      "url": "https://your_domain.com/webhook/twitter/0",
      "valid": true,
      "created_at": "2016-06-02T23:54:02Z"
    }

エラーメッセージ

Code	Message
214	Webhook URL が要件を満たしていません。
214	既に作成済みのリソースが多すぎます。
214	Webhook URL が要件を満たしていません。CRC トークンが無効であるか、JSON レスポンスの形式が正しくありません。
214	CRC GET リクエストのレイテンシが高すぎます。Webhook は 3 秒未満で応答する必要があります。
214	CRC GET リクエスト中に 200 以外のレスポンスコード (例：404、500 など) が返されました。

HTTP 403

    {
      "errors": [
        {
          "code": 214,
          "message": "Too many resources already created."
        }
      ]
    }

GET account_activity/webhooks

指定されたアプリケーションに対するすべての URL とそのステータスを返します。 URL が日次の検証チェックに失敗した場合、その URL は無効としてマークされます。URL を再度有効にするには、update エンドポイントを呼び出してください。

リソースURL

https://api.x.com/1.1/account_activity/webhooks.json

リソース情報


レスポンス形式	JSON
認証が必要	はい (アプリケーションのみ・ベアラートークン)
レート制限	あり
15分あたりのリクエスト数 (アプリケーション認証)	15

リクエスト例

    $ curl --request GET
     --url https://api.x.com/1.1/account_activity/webhooks.json
     --header 'authorization: Bearer TOKEN'

レスポンス例

HTTP 200 OK

    [
      {
        "id": "1234567890",
        "url": "https://your_domain.com/webhook/twitter/0",
        "valid": true,
        "created_at": "2016-06-02T23:54:02Z"
      }
      {
        "id": "2468013579",
        "url": "https://your_domain2.com/webhook/twitter/0",
        "valid": true,
        "created_at": "2016-06-04T22:31:29Z"
      }
    ]

エラーメッセージ

コード	メッセージ
99	このリソースにアクセスする権限がありません。

PUT account_activity/webhooks/:webhook_id

指定した webhook の URL に対してチャレンジレスポンスチェック (challenge response check、CRC) をトリガーします。チェックが成功した場合、204 を返し、その webhook のステータスを valid に設定して再度有効化します。

リソース URL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json

リソース情報


レスポンス形式	JSON
認証が必要	はい (ユーザーコンテキスト - すべてのコンシューマーキーおよびアクセストークン)
レート制限あり	はい
リクエスト数 / 15 分間ウィンドウ (ユーザー認証)	15

パラメータ


webhook_id (必須)	Webhook ID。リソースパスで定義されます。

リクエストの例

    $ curl --request PUT
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
     --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'

レスポンス

HTTP 204 OK

{ }

エラーメッセージ

Code	メッセージ
34	Webhook が存在しないか、別の X アプリケーションに関連付けられています。
214	Webhook URL が要件を満たしていません。
214	Webhook URL が要件を満たしていません。CRC トークンが無効であるか、JSON レスポンス形式が不正です。
214	CRC GET リクエストのレイテンシーが高すぎます。Webhook は 3 秒未満で応答する必要があります。
214	CRC GET リクエスト時に 200 以外のレスポンスコードが返されました (例: 404、500 など)。

POST account_activity/webhooks/:webhook_id/subscriptions/all

指定したユーザーコンテキストについて、すべてのメッセージ種別に関するすべてのイベントを、指定したアプリケーションに配信するよう登録します。有効化後は、リクエストしたユーザーに関するすべてのイベントが、POST リクエストを通じてアプリケーションの webhook に送信されます。サブスクリプション数は現在、ご利用のアカウント設定に基づき制限されています。さらにサブスクリプションを追加する必要がある場合は、担当のアカウントマネージャーまでお問い合わせください。

リソースURL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

リソース情報


レスポンス形式	JSON
認証が必要	はい (3-legged OAuth - ホワイトリスト登録されたコンシューマーキーと購読ユーザーのアクセストークン)
レート制限	あり
リクエスト数 / 15分間のウィンドウ (ユーザー認証)	500

パラメータ


webhook_id (必須)	Webhook の id。リソースパスで定義されます。

サンプルリクエスト

    $ curl --request POST
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
     --header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBING_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

レスポンス例 - 成功時

HTTP 204 NO CONTENT

{}

エラーメッセージ

コード	メッセージ
34	webhook が存在しないか、別の X アプリケーションに関連付けられています。
348	クライアントアプリケーションには、このユーザーの webhook サブスクリプションへのアクセス権がありません。

GET account_activity/subscriptions/count

あなたのアカウントで現在アクティブなサブスクリプション数を返します。/count エンドポイントにはアプリケーション専用の OAuth 認証が必要なため、ユーザーコンテキストではなくベアラートークンを使用してリクエストを行う必要があります。

リソース URL

https://api.x.com/1.1/account_activity/subscriptions/count.json

リソース情報


レスポンス形式	HTTP レスポンスコード
認証が必要	はい (App-only - ベアラートークン)
レート制限	あり
リクエスト数 / 15 分間ウィンドウ (アプリケーション認証)	15

HTTP レスポンスコード


Code	Message
200	成功。要求された webhook に対するサブスクリプション数が返されます。
401	指定された webhook のサブスクリプションを閲覧する権限が App にありません。

リクエスト例

    $ curl --request GET
     --url https://api.x.com/1.1/account_activity/subscriptions/count.json
     --header 'authorization: Bearer TOKEN'

成功時のレスポンス例

HTTP 200

    {
      "account_name":"my-account",
      "subscriptions_count_all":"1",
      "subscriptions_count_direct_messages":"0",
      "provisioned_count":"50"
    }

エラーメッセージ

Code	Message
32	認証に失敗しました。

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "Could not authenticate you."
        }
      ]
    }

GET account_activity/webhooks/:webhook_id/subscriptions/all

指定したユーザーのイベントに対して、ある webhook 設定がサブスクライブされているかどうかを判定する手段を提供します。指定したユーザーコンテキストが、指定したアプリケーションで有効なサブスクリプションを持っている場合は、204 OK を返します。レスポンスコードが 204 でない場合、そのユーザーには有効なサブスクリプションがありません。詳細については、以下の HTTP レスポンスコードおよびエラーメッセージを参照してください。

リソースURL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

リソース情報


レスポンス形式	JSON
認証が必要	はい (3-legged OAuth - ホワイトリスト登録済みコンシューマーキーと購読ユーザーのアクセス・トークン)
レート制限	はい
リクエスト数 / 15分間ウィンドウ (ユーザー認証)	500

パラメーター


webhook_id (required)	Webhook ID。リソースパスで定義されます。

リクエスト例

$ curl —request GET —url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json —header ‘authorization: OAuth oauth_consumer_key=“WHITELISTED_CONSUMER_KEY”, oauth_nonce=“GENERATED”, oauth_signature=“GENERATED”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“GENERATED”, oauth_token=“SUBSCRIBING_USER’S_ACCESS_TOKEN”, oauth_version=“1.0“‘

サンプルレスポンス - 成功時

HTTP 204 NO CONTENT

{ }

GET account_activity/webhooks/:webhook_id/subscriptions/all/list

指定された webhook に対する、現在有効な All Activity タイプのサブスクリプションのリストを返します。/list エンドポイントではアプリケーション専用の OAuth が必要なため、リクエストはユーザーコンテキストではなくベアラートークンを使用して行う必要があります。

リソース URL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all/list.json

リソース情報


レスポンス形式	HTTP レスポンスコード
認証が必要	はい (アプリケーション認証のみ - ベアラートークン)
レート制限	はい
リクエスト数 / 15 分間ウィンドウ (アプリケーション認証)	50

パラメーター


webhook_id (required)	Webhook の ID。リソースパスで定義されます。

HTTP Response Codes

Code	Message
200	成功。指定された webhook のサブスクリプションリストが返されます。
401	ご利用のアプリケーションには、指定された webhook のサブスクリプションを表示する権限がありません。

リクエスト例

$ curl —request GET —url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all/list.json —header ‘authorization: Bearer TOKEN’

レスポンス例 - 成功時

HTTP 200

    {
      "webhook_id": "1234567890",
      "webhook_url": "https://your_domain.com/webhook/twitter/0",
      "application_id": "11231812",
      "subscriptions": [{
        "user_id": "20212306"
      }]
    }

エラーメッセージ

Code	Message
32	認証に失敗しました。

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "Could not authenticate you."
        }
      ]
    }

DELETE account_activity/webhooks/:webhook_id

指定されたアプリケーションの設定から Webhook を削除します。Webhook ID は、GET /1.1/account_activity/webhooks エンドポイントを呼び出すことで取得できます。

リソース URL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json

リソース情報


レスポンス形式	JSON
認証が必要	はい (ユーザーコンテキスト - すべてのコンシューマーおよびアクセストークン)
レート制限	あり
リクエスト数 / 15 分間ウィンドウ (ユーザー認証)	15

パラメータ


webhook_id (required)	Webhook の識別子。リソースパスで定義されます。

リクエスト例

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
     --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'

レスポンス

HTTP 204 OK

{ }

DELETE account_activity/webhooks/:webhook_id/subscriptions/all (非推奨)

指定されたユーザーコンテキストとアプリケーションに対するサブスクリプションを無効化します。無効化後は、リクエスト元ユーザーに関するすべてのイベントは、webhook URL に送信されなくなります。

リソース URL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

リソース情報


レスポンス形式	JSON
認証が必要	はい (3-legged OAuth - ホワイトリスト登録済みのコンシューマーキーと購読ユーザーのアクセストークン)
レート制限	あり
リクエスト数 / 15分ウィンドウ (ユーザー認証)	500

パラメータ


webhook_id (required)	Webhook ID。リソースパスで定義されます。

リクエスト例

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
     --header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBED_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

リクエスト例

{ }

DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json

指定された webhook とユーザーidに対するサブスクリプションを無効化します。無効化後、リクエストを行ったユーザーに関するすべてのイベントは、webhook の URL には送信されなくなります。なお、このエンドポイントはアプリケーション専用 OAuth が必要となるため、リクエストはユーザーコンテキストではなくベアラートークンを使用して行う必要があります。

リソース URL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json

リソース情報


レスポンス形式	JSON
認証が必要	はい (アプリケーションのみ - ベアラートークン)
レート制限	あり
15分間あたりのリクエスト数	500

リクエスト例

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
     --header 'authorization: Bearer TOKEN'

レスポンス

HTTP 204 NO CONTENT

エラーメッセージ

Code	Message
404	申し訳ありません。そのページは存在しません。- 指定されたユーザー id が実際には購読対象になっていない場合によく発生します。

Replay API

POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json ¶ リクエストで指定された日時のウィンドウ内に存在していたすべてのサブスクリプションについて、過去最大5日分のアクティビティを取得するリクエストを送信します。Webhook にアクティブなユーザーサブスクリプションがある場合、それらのイベントも同時に受信します。注記: Replay イベントを配信する前に CRC を実行します。


Request Method	HTTP POST
URL	/1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm
Response Format	JSON
Requires Authentication	Yes (application only - ベアラートークン)
Rate Limit	15分あたり5リクエスト。現在、リクエスト可能な Replay ジョブ数の上限はありません。
from_date	イベントが提供される最も古い (開始) UTC タイムスタンプで、‘yyyymmddhhmm’ 形式で指定する必要があります。タイムスタンプは分単位の粒度で、包括的です (例: 12:00 は 00 分を含みます) 。有効な時刻は、過去5日以内の UTC 時刻であり、現在時刻より31分以上前である必要があります。from_date と to_date はおおよそ2時間以内に収まるようにすることを推奨します。
to_date	イベントが提供される最新 (終了) の UTC タイムスタンプで、‘yyyymmddhhmm’ 形式で指定する必要があります。タイムスタンプは分単位の粒度で、排他的です (例: 12:30 はその時間の30分を含みません) 。有効な時刻は、過去5日以内の UTC 時刻であり、現在時刻より10分以上前である必要があります。

レスポンス

API からは次のレスポンスが返される可能性があります。ほとんどのエラーコードでは、ボディに追加の詳細を含む文字列が返されます。200 以外のステータスコードのレスポンスの場合は、エラーを解消してから再試行してください。

Status	Text	Error Code	Description	Message
202	Accepted	N/A	リクエストは成功し、アクティビティが送信されます。	N/A
400	Bad Request	214	Webhook が無効としてマークされています。	Webhook は無効とマークされており、CRC チェックが必要です。
400	Bad Request	357	クエリパラメーターが不足しています。	: queryParam が必須です。
400	Bad Request	358	ルートまたはクエリパラメーターの形式が正しくありません。	パラメーターを解析できません。
400	Bad Request	360	ルートパラメーターが負の値です。	webhook_id: [] は 0 以上ではありません。
400	Bad Request	368	from_date または to_date が過去の日付ではありません。	: [<field_value>] は過去の日付ではありません。
400	Bad Request	356	from_date は to_date より前でなければなりません。	from_date は to_date より前でなければなりません。
400	Bad Request	356	from_date は過去 5 日以内でなければなりません。	from_date は過去 5 日以内でなければなりません。
401	Unauthorized	32	3-legged 認証が提供されたため、HTTP 認証に失敗しました。	認証方法が無効です。application-only 認証を使用してください。
401	Unauthorized	61	Client にはこのメソッドをリクエストする権限がありません。	Client にはこのメソッドをリクエストする権限がありません。
403	Forbidden	200	Client に Replay が有効なエンタープライズアカウントがありません。	Replay が有効な Account Activity API エンタープライズアカウントが必要です。エンタープライズアカウントを保有し、Replay が有効になっていることを確認してください。
404	Not Found	34	存在しない webhook_id、または webhook_id と application_id の不一致です。	Webhook が存在しないか、別の X アプリケーションに関連付けられています。
409	Conflict	355	進行中のリクエストがあり、別のリクエストを行う前にその処理が完了する必要があります。	この Webhook に対する Replay ジョブがすでに進行中です。
429	Too Many Requests	88	レート制限に達しました (一定時間あたりのリクエスト数の上限に到達) 。	リクエストが多すぎます。API リクエストレートを下げてください。
500	Internal Server Error	0	内部サーバーエラーです。	内部サーバーエラーです。
503	Service Unavailable	67	X 上の 1 つ以上の依存サービスが利用できません。	X サーバーエラーです。指数バックオフ方式で再試行してください。

“Job completed successfully” メッセージ

ジョブが正常に完了すると、Account Activity Replay API は次のジョブ完了イベントを送信します。このイベントを受信した時点で、そのジョブの実行は終了しており、新たに別のジョブを送信できます。

{
  "replay\_job\_status": {
    "webhook_id": "1234577122340233217",
    "job_state": "Complete",
    "job\_state\_description": "Job completed successfully"
    "job_id": "1095098195724558337"
  }
}

“ジョブが完了しませんでした” メッセージ

ジョブが正常に完了しなかった場合、Replay ジョブの再試行を促すために、次のメッセージを返します。このイベントを受信した時点で、そのジョブの実行は終了しており、別のジョブを送信できます。

{
  "replay\_job\_status": {
    "webhook_id": "123451374207332352",
    "job_state": "Incomplete",
    "job\_state\_description": "Job failed to deliver all events, please retry your replay job",
    "job_id": "1093226942650736640"
  }
}

curl のリクエスト例

    curl --request POST  --url 'https://api.x.com/1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm'
    --header 'authorization: Bearer TOKEN'

レスポンス例

HTTP 202

{
  "job_id": "1234567890",
  "created_at": "2016-06-02T23:54:02Z"
}