このエンドポイントは、ポスト編集メタデータを含むように更新されました。これらのメタデータの詳細については、“ポストを編集” の基礎ページをご覧ください。 このエンドポイントは、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 受信 (ユーザー宛て)
* 入力中インジケーター (ユーザー宛て)
* 既読通知 (ユーザー宛て)
* 購読取り消し (ユーザーによる) |
| ティア | 料金 | 一意のサブスクリプション数 | Webhook の数 | 信頼性とアクティビティ復旧 |
|---|
| Enterprise | 営業担当に問い合わせ | 最大 500+ | 3 以上 | 再試行 および リプレイ |
-
ご不明な点がありますか？ エラーが発生していますか？
-
サンプルコードを試してみてください：
⏱ 読了時間 10 分
Enterprise Account Activity API は、あなたのサービスに購読している X アカウントでイベントが発生するたびに、webhook ベースの JSON メッセージを提供します。X はそれらのアクティビティを、登録済みの webhook に配信します。以下の手順では、webhook と購読ユーザーの管理方法を説明します。
ここでは、webhook と購読ユーザーの登録、確認、削除の方法を説明します。各種 API エンドポイントへのリクエスト送信には、シンプルな cURL コマンドを使用します。cURL は、URL 構文を使ってリクエストの送受信を行うコマンドラインツールです。
次のものが必要です:
作業を始める前に、X の Account Activity API を使い始めるためのサンプル Web アプリや補助スクリプトを提供している こちらの GitHub リポジトリ をご覧いただくことをおすすめします。
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
サブスクリプションの追加
サブスクリプションの確認
サブスクリプションの削除
すべてのイベントタイプを受信できるよう、まずユーザーをサブスクリプションに追加するところから始めます。次の項目を変更したうえで、以下の 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"'
Account Activity API のビデオウォークスルー
- webhook の登録
- ユーザーサブスクリプションの追加
- ユーザーサブスクリプションの削除
- アカウントアクティビティの受信
- アカウントアクティビティのリプレイ
-
質問がありますか？ エラーが発生していますか？
-
サンプルコードを参照してください:
Enterprise
Account Activity API は、開発・デプロイ・ホストした Web アプリにアカウントイベントを送信する、Webhook ベースの API です。
イベントコンシューマーアプリケーションで Webhook イベントの受信を開始する前に、いくつかの「下準備」となる作業があります。以下のとおり、X の App を作成し、Account Activity API へのアクセス権を取得し、Webhook イベントを受信して処理する Web アプリを開発する必要があります。
- 開発者コンソール で承認済みの開発者アカウントを使用して 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 アクセスを取得する
3. Webhook コンシューマー App を開発する
-
イベントを受信するための webhook として使用する URL を持つ Web アプリを作成します。これは、X の webhook からの着信イベントをリッスンするためにサーバー上にデプロイするエンドポイントです。
-
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 リクエストを送信します。詳細は、サブスクリプションの追加に関するガイド を参照してください。
- 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 の応答を送信することもできます。
-
コード例はこちらを参照してください:
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 へのイベント送信は停止します。
- 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 レスポンスコード
Python におけるレスポンストークン生成の例:
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)
{
"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 の情報セキュリティチームにより強く推奨されています。以下の推奨事項に馴染みがない、または内容がよく分からない場合は、サーバー管理者に相談してください。
セキュリティをさらに強化するため、次の集約ネットワークブロックを許可リストに追加することを検討してください。
-
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 の URL を変更するには、既存の 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 を更新するだけではだめなのはなぜですか？
ご注意ください: Account Activity API を利用開始する前に、まず X 側で開発者用 App に対して Account Activity API へのアクセスを有効化してもらう必要があります。そのため、認証に使用する予定の App ID をアカウントマネージャーまたはテクニカルサポートチームと必ず共有してください。
- Consumer Keys (API Key と Secret)
- Access Tokens (Access Token と Secret)
次の 3 つのエンドポイントでは、アプリケーションのコンテキスト内で書き込み操作を実行します (X ユーザーは関与しません) 。そのため、指定する必要がある Access Token は、あなたの開発者 App に属するものです。これらは 開発者コンソール 内の、該当する App の「Keys and tokens」タブから直接生成できます。
一方、以下の 3 つのエンドポイントでは、アプリケーションが X ユーザー (たとえばダイレクトメッセージなど) の保護されたデータに、ユーザーの代理としてアクセスできるようにするリクエストを送信します。そのため、対象となる購読ユーザーに属する Access Token を必ず指定する必要があります。必要な Access Token は、3-legged OAuth フローを使用して取得できます (OAuth 1.0a: how to obtain a user’s Access Tokens を参照) 。これらのエンドポイントは、上記の表ではアスタリスク (*) でマークされています。
ご注意: 開発者 App が「Read, Write, and Direct Messages」に有効化されていることを確認してください。この設定は、開発者アカウントの Projects & Apps セクションの、対象の開発者 App の「App permissions」で変更できます。権限設定を変更した後は、App の認証情報を再生成する必要があります。 ご注意: Account Activity API を利用開始する前に、X 側で開発者 App に対して Account Activity API へのアクセスを有効化する必要があります。そのため、認証に使用する予定の App ID を、アカウントマネージャーまたはテクニカルサポートチームと必ず共有してください。
- Consumer Keys (API Key と Secret)
- Access Tokens (Access Token と Secret)
次の 3 つのエンドポイントの場合、アプリケーションのコンテキスト内で書き込み操作を実行します (X ユーザーは関与しません) 。そのため、提供する必要がある Access Token は、あなたの開発者 App に属するものです。これらは、開発者コンソール 内の App の「Keys and tokens」タブから直接生成できます。
一方、次の 3 つのエンドポイントでは、X ユーザー (たとえば Direct Messages) の保護されたデータへ、アプリケーションがユーザーに代わってアクセスできるようにするリクエストを行います。そのため、対象となるサブスクライブユーザーに属する Access Token を指定する必要があります。必要な Access Token は 3-legged OAuth フローを使用して取得できます (OAuth 1.0a: how to obtain a user’s Access Tokens を参照) 。これらのエンドポイントには、上記の表内でアスタリスク (*) が付いています。
ご注意ください: 開発者 App が「Read, Write, and Direct Messages」に有効になっていることを確認してください。この設定は、開発者アカウントの Projects & Apps セクション内で、対象の開発者 App の「App permissions」から変更できます。権限設定を変更した後は、App クレデンシャルを再生成する必要があります。 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 | コンプライアンスを容易に維持できるようにするための、削除された投稿の通知です。 |
{
"for_user_id": "2244994945",
"tweet_create_events": [
{
<Tweet Object>
}
]
}
{
"for_user_id": "2244994945",
"user_has_blocked": "false",
"tweet_create_events": [
{
<Tweet Object>
}
]
}
{
"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>
}
}]
}
{
"for_user_id": "2244994945",
"follow_events": [{
"type": "follow",
"created_timestamp": "1517588749178",
"target": {
<User Object >
},
"source": {
< User Object >
}
]
}
}
{
"for_user_id": "2244994945",
"follow_events": [{
"type": "unfollow",
"created_timestamp": "1517588749178",
"target": {
<User Object >
},
"source": {
< User Object >
}
]
}
}
{
"for_user_id": "2244994945",
"block_events": [{
"type": "block",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}]
}
{
"for_user_id": "2244994945",
"block_events": [{
"type": "unblock",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}]
}
{
"for_user_id": "2244994945",
"mute_events": [
{
"type": "mute",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}
]
}
{
"for_user_id": "2244994945",
"mute_events": [
{
"type": "unmute",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}
]
}
{
"user_event": {
"revoke": {
"date_time": "2018-05-24T09:48:12+00:00",
"target": {
"app_id": "13090192"
},
"source": {
"user_id": "63046977"
}
}
}
}
{
"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"
}
}
}
{
"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 の使用
- 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 については追加機能も備えた新しいエンドポイントとサービスが用意されています。
これらの新しいエンドポイントやサービスへのスムーズな移行を支援するため、以下の 2 つの移行ガイドを用意しています。
さらに、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 への移行
以下の手順に従って、Site Streams API から Account Activity API へ簡単に移行できます
- 必要な 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 からの移行ではない場合)
Account Activity ダッシュボード (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 |
変更概要
以下のDMエンドポイントをまだ使用している場合は、新しいエンドポイントへ移行する必要があります。
新しい 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!"}}}}'
- メッセージは 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 のセットアップ方法について、ステップバイステップのガイドはありますか？
あります。
システムが一定時間ダウンした場合、データを復旧する方法はありますか？
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 分後に再配信が可能になります。
このエラーは一般的に、指定しているリクエスト、ヘッダー、認可、または 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 は大文字と小文字を区別する点に注意してください。
-
Premium - API にリクエストを送信する前に、承認済みの開発者アカウントを持っていることを確認してください。また、リクエスト内で適切な :env_name を使用する必要があります。これは dev environments ページで設定できます。
-
Enterprise - アカウントマネージャーが、Account Activity API へのアクセス権を付与していることを確認してください。
-
URI を正しく設定していることを確認してください。リクエストで誤った URI を指定している場合、このエラーが発生する可能性があります。
コード 214 - webhook URL が要件を満たしていません。
Code 214 - CRC GET リクエストでレイテンシーが高い状態です。Webhook は 3 秒以内に応答する必要があります。
- これは、サーバーの処理が遅いことを意味します。CRC に 3 秒以内に応答していることを確認してください。
コード 214 - CRC GET リクエスト中の 200 以外のレスポンスコード (例: 404、500 など)
- サーバーがダウンしている可能性があります。サーバーが正常に稼働していることを確認してください。
コード 214 - 作成済みリソースが多すぎます。
- Enterprise - すでに利用可能な webhook をすべて使い切っています。登録済みの各 App について GET webhooks エンドポイントを使用し、webhook がどこに割り当てられているかを特定してください。
- 使用している 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 リファレンスインデックス
POST account_activity/webhooks
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 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 など) が返されました。 |
{
"errors": [
{
"code": 214,
"message": "Too many resources already created."
}
]
}
GET account_activity/webhooks
リソース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'
[
{
"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
valid に設定して再度有効化します。
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"'
| 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
リソース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 認証が必要なため、ユーザーコンテキストではなくベアラートークンを使用してリクエストを行う必要があります。
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"
}
エラーメッセージ
HTTP 401
{
"errors": [
{
"code": 32,
"message": "Could not authenticate you."
}
]
}
GET account_activity/webhooks/:webhook_id/subscriptions/all
リソース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
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all/list.json
リソース情報
| |
|---|
| レスポンス形式 | HTTP レスポンスコード |
| 認証が必要 | はい (アプリケーション認証のみ - ベアラートークン) |
| レート制限 | はい |
| リクエスト数 / 15 分間ウィンドウ (アプリケーション認証) | 50 |
| |
|---|
| webhook_id (required) | Webhook の ID。リソースパスで定義されます。 |
| 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"
}]
}
{
"errors": [
{
"code": 32,
"message": "Could not authenticate you."
}
]
}
DELETE account_activity/webhooks/:webhook_id
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"'
DELETE account_activity/webhooks/:webhook_id/subscriptions/all (非推奨)
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
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'
| Code | Message |
|---|
| 404 | 申し訳ありません。そのページは存在しません。- 指定されたユーザー id が実際には購読対象になっていない場合によく発生します。 |
| |
|---|
| 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分以上前である必要があります。 |
| 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” メッセージ
{
"replay\_job\_status": {
"webhook_id": "1234577122340233217",
"job_state": "Complete",
"job\_state\_description": "Job completed successfully"
"job_id": "1095098195724558337"
}
}
{
"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 --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"
}
