Account Activity API: Enterprise

このendpointは、Postの編集metadataを含むように更新されました。これらのmetadataの詳細は”Edit Posts” の基礎ページをご覧ください。このendpointはダイレクトメッセージのendpointと併用されることがよくあります。新しいv2 ダイレクトメッセージのendpointを公開しました。なお、EnterpriseおよびPremiumのAccount Activity APIはv2の1対1メッセージをサポートしていますが、グループ会話はまだサポートしていません。

概要 Enterprise Account Activity APIは、webhookを通じてユーザーアカウントに関連するリアルタイムアクティビティを購読できる機能を提供します。これにより、単一の接続で、所有または購読している1つ以上のアカウントから、リアルタイムのPosts、ダイレクトメッセージ、その他のアカウントイベントを受信できます。 webhook登録の各ユーザー購読について、以下の関連アクティビティをすべて受信します:

アクティビティの種類
* Posts（ユーザーによる） * Postの削除（ユーザーによる） * @メンション（ユーザー宛） * 返信（ユーザーへの／ユーザーからの） * リツイート（ユーザーによる／ユーザーの投稿の） * 引用Tweet（ユーザーによる／ユーザーの投稿の） * 引用Tweetのリツイート（ユーザーによる／ユーザーの投稿の） * like（ユーザーによる／ユーザーの投稿への） * フォロー（ユーザーによる／ユーザーの） * フォロー解除（ユーザーによる）	* ブロック（ユーザーによる） * ブロック解除（ユーザーによる） * ミュート（ユーザーによる） * ミュート解除（ユーザーによる） * ダイレクトメッセージ送信（ユーザーによる） * ダイレクトメッセージ受信（ユーザーによる） * 入力中インジケーター（ユーザー宛） * 既読通知（ユーザー宛） * 購読の取り消し（ユーザーによる）

アクティビティの種類

* Posts（ユーザーによる）

* Postの削除（ユーザーによる）
* @メンション（ユーザー宛）
* 返信（ユーザーへの／ユーザーからの）
* リツイート（ユーザーによる／ユーザーの投稿の）
* 引用Tweet（ユーザーによる／ユーザーの投稿の）
* 引用Tweetのリツイート（ユーザーによる／ユーザーの投稿の）
* like（ユーザーによる／ユーザーの投稿への）
* フォロー（ユーザーによる／ユーザーの）

* フォロー解除（ユーザーによる）

* ブロック（ユーザーによる）
* ブロック解除（ユーザーによる）
* ミュート（ユーザーによる）
* ミュート解除（ユーザーによる）
* ダイレクトメッセージ送信（ユーザーによる）
* ダイレクトメッセージ受信（ユーザーによる）
* 入力中インジケーター（ユーザー宛）
* 既読通知（ユーザー宛）
* 購読の取り消し（ユーザーによる）

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

動画シリーズ

Account Activity API の全4回の動画シリーズで最新情報をキャッチアップしましょう。

機能概要

ティア	価格	一意のサブスクリプション数	webhook 数	信頼性とアクティビティ復旧
Enterprise	営業にお問い合わせ	最大500+	3+	再試行とリプレイ

ご不明点がありますか？エラーが発生していますか？
- よくある質問またはエラーのトラブルシューティングガイドをご覧ください。
サンプルコードを見る:
- Enterprise Account Activity API ダッシュボード：Account Activity API の Enterprise ティアで webhook イベントを表示し、リプレイ機能を備えた Node 製の Web アプリ。
- SnowBot チャットボット：Enterprise の Account Activity API と Direct Message API を基盤とした Ruby 製の Web アプリ。

webhook と購読ユーザーを管理する

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

登録済みの X App - こちらで登録
Bearer Token - 詳細はこちら
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 を登録したら、Account Activity API にサブスクライブ済みユーザーを追加して、そのユーザーのアカウントアクティビティの受信を開始できます。

サブスクリプションを追加する
サブスクリプションの表示
サブスクリプションを削除する

まず、ユーザーをサブスクライブして、すべてのイベントタイプを受信できるようにします。以下の値を適切に置き換えたうえで、次の cURL リクエストをコマンドラインにコピーしてください。

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

サブスクライブ対象ユーザーの access token <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 とサブスクライブ済みユーザーを管理できるようになったはずです。

参照記事

Account Activity API の動画ウォークスルー

この動画ウォークスルーでは、Account Activity API のプレミアムおよび Enterprise ティアで利用できる機能について学びます。動画を見終えると、次の内容を理解できます。

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

ご不明点やエラーはありませんか？
- よくある質問またはエラーのトラブルシューティングガイドをご覧ください。
サンプルコードを見る:
- Enterprise Account Activity API dashboard：Account Activity API の Enterprise ティアを用いて webhook イベントを表示し、Replay 機能も備えた Node ベースの Web アプリです。
- SnowBot chatbot：Enterprise の Account Activity API と Direct Message API の上に構築された Ruby 製の Web アプリです。

Enterprise

webhook のはじめに

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

1. X App を作成します。

developer portalで承認済みのデベロッパーアカウントを使用して、X Appを作成します。会社を代表して作成する場合は、企業の X アカウントでの作成を推奨します。デベロッパーアカウントに申請するには、こちらから行ってください。
アプリページのpermissionsタブで「Read, Write and Access direct messages」を有効にします。
“Keys and Access Tokens” タブで、アプリの Consumer Key (API Key) と Consumer Token (API Secret) を控えておきます。
同じタブで、アプリのAccess Token and Access Token Secretを生成します。これらの Access Tokens は、X がアカウントイベントを送信する先となる webhook URL を登録する際に必要です。
X Sign-inや X API におけるユーザーコンテキストの仕組みに不慣れな場合は、Obtaining Access Tokensを確認してください。イベントを受信するアカウントを追加する際は、そのアカウントの access tokens を使用してサブスクライブします。
developer portalの”Apps”ページに表示されるアプリの数値 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 イベントを受け取るためにサーバー上にデプロイする endpoint です。
- 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= endpoint に POST リクエストを送信します。このリクエストを行うと、X はあなたの Web アプリに CRC リクエストを送ります。webhook が正常に登録されると、レスポンスに webhook の id が含まれます。この webhook の id は、後で一部の Account Activity API リクエストで必要になります。
X は、登録した URL にアカウントの webhook イベントを送信します。受信イベントに対して Web アプリが POST リクエストを受け付けるようにしておいてください。イベントは JSON でエンコードされます。webhook の JSON ペイロード例はこちらを参照してください。
Web アプリの準備ができたら、次はアクティビティを受信するアカウントを追加します。アカウントを追加（または削除）する際は、アカウントの id を参照する POST リクエストを送信します。詳細はサブスクリプションの追加に関するガイドを参照してください。

4. セットアップの検証

App と webhook が正しく構成されているかを検証するには、App が購読している X アカウントのいずれかが投稿した Post を「いいね」してください。購読者が受け取った各「いいね」について、webhook の URL 宛てに POST リクエストで favorite_events が届くはずです。
購読を追加してからイベントの配信が開始されるまで、最大 10 秒程度かかる場合があります。

重要な注意事項

webhook の URL を登録する際、Web アプリは consumer token と secret「に加えて」、App オーナーのユーザー access token と secret で認証する必要があります。
受信したすべてのダイレクトメッセージは webhook 経由で配信されます。さらに、POST direct_messages/events/new (message_create) 経由で送信されたダイレクトメッセージもすべて webhook 経由で配信されます。これは、別のクライアントから送信されたダイレクトメッセージも Web アプリが把握できるようにするためです。
すべての webhook イベントには、そのイベントがどの購読向けに配信されたかを示す for_user_id のユーザー ID が含まれます。
同じ会話で 2 人のユーザーがあなたの Web アプリを使ってダイレクトメッセージをやり取りしている場合、webhook には同一内容のイベントが 2 件（各ユーザー分）届きます。Web アプリ側で考慮してください。
複数の Web アプリが同じ webhook URL を共有し、各 App に同一のユーザーをマッピングしている場合、同じイベントが（Web アプリごとに 1 回）複数回送信されます。
場合によっては、webhook に重複イベントが届くことがあります。webhook アプリはこれを許容し、event ID で重複排除してください。
Quick Reply の応答がリクエスト直後に必ず返るとは限りません。ユーザーは Quick Reply のリクエストを無視して従来のダイレクトメッセージで応答することもできます。また、ユーザーがメッセージスレッド内で以前に返信していないリクエストに対して Quick Reply で応答する場合もあります。
コード例:
- Enterprise Account Activity API dashboard: Account Activity API の Enterprise ティアを用いて webhook イベントを表示する Node 製の Web アプリで、Replay 機能を備えています。
- SnowBot chatbot: Account Activity とダイレクトメッセージ API 上に構築された Ruby 製の Web アプリです。このコードベースには、Account Activity API の webhook 設定を支援するための script が含まれています。

webhook の保護

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

チャレンジレスポンス方式の検証により、webhook イベントを受信する Web アプリの所有権を X が確認します。
各 POST リクエストの署名ヘッダーにより、受信した webhook の送信元が X であることを確認できます。

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

あなたがAppおよびwebhook URLの所有者であることを検証するために、XはChallenge-Response Check（CRC）を実行します。これは巡回冗長検査（cyclic redundancy check）と混同しないでください。CRCが送信されると、XはあなたのWebアプリに対して、crc_token パラメータ付きで 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をトリガーすることもできます。新しいコードをデプロイしてサービスを再起動した後など、webhookアプリケーションを開発する際にCRCをトリガーするのは有用です。 crc_token は受信する各CRCリクエストごとに変更されることを想定し、計算においてメッセージとして使用し、Consumer Secret を鍵として使用してください。レスポンスが3秒以内に返されない、または無効になった場合、イベントは登録済みwebhookへの送信が停止されます。

CRC リクエストが発生するタイミング:

webhook URL が登録されたとき。
webhook URL を検証するため、概ね_毎時_。
PUT リクエストを送信すると、CRC を手動でトリガーできます。webhook クライアントを開発する際は、CRC レスポンスの実装と並行して、CRC を手動でトリガーできるように計画してください。

レスポンス要件:

crc_token と App の Consumer Secret から生成した、base64 エンコードの HMAC-SHA256 hash
有効な response_token と JSON 形式
レイテンシは 3 秒未満
HTTP ステータスコード 200

言語別の HMAC ライブラリ：

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

以下は、Python 2.7 の Flask 製 Web アプリで、チャレンジレスポンス検証に正しく応答するルートを定義する例です。

import base64
import hashlib
import hmac
import json


\# GETリクエスト用のルートを定義
@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 レスポンスの例:

上記のようにルートを定義していれば、ウェブブラウザで https://your-app-domain/webhooks/twitter?crc_token=foo にアクセスした際、webapp は以下のようなレスポンスを返します。

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

その他の例:

HERE は、Node/JS で実装された CRC 応答メソッドの例です。
HERE は、Ruby で実装された CRC 応答メソッドの例です（generate_crc_response と、CRC イベントを受信する /GET ルートを参照）。

任意の署名ヘッダー検証

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

token&amp;nonce=

nonce から計算されます。 リクエストを検証する手順

Consumer Secret と受信したペイロード本文を用いてハッシュを作成します。
作成したハッシュを、base64 エンコードされた x-twitter-webhooks-signature の値と比較します。タイミング攻撃への耐性を高めるために、compare_digest などの手法を使用してください。

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

以下は、Web アプリケーションで検討すべき追加のセキュリティガイドラインです。これらのガイドラインを実装していなくても webhook の動作自体は妨げられませんが、X Information Security チームが強く推奨しています。以下の推奨事項に不慣れな場合は、サーバー管理者にご相談ください。

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 圧縮を無効化
セッションチケットキーをローテーションしない限り、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 設定管理 endpoint:


メソッド	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 が変更された場合、App の consumer key と consumer secret が漏えいしている可能性があります。新しい webhook 設定の作成を求めることで、ユーザーのイベントへの再購読も必須になります。これには、悪意ある第三者が保有している可能性が低い access token の使用が必要です。その結果、他者がユーザーの非公開情報を受け取ってしまう可能性を低減できます。

ユーザーサブスクリプションの追加と削除

数千件規模のサブスクリプションに対応するサポートは、Enterprise ティアで利用可能です。すでにアカウントマネージャーがいる場合は、質問があれば担当者までお問い合わせください。Enterprise API へのアクセスを申請するには、こちらをご覧ください。

サブスクリプション管理 endpoints


Method	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

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

Account Activity API は、単一の接続で、購読中のすべてのアカウントのリアルタイムなアカウントアクティビティを受信するためのユーザーサブスクリプションを作成・管理できる一連の endpoints で構成されています。 Account Activity API では 2 種類の認証方式（OAuth 1.0a と OAuth 2.0 Bearer Token）が利用可能です。使用する認証方式は、利用する endpoint によって異なります。


説明	Endpoint	OAuth 1.0a (ユーザーコンテキスト)	OAuth 2.0 Bearer Token (アプリケーション専用)
指定されたアプリケーションのコンテキストに対して新しい webhook の URL を登録します	POST account_activity/webhooks	✓
指定されたアプリケーションのすべての URL とそれぞれのステータスを返します	GET account_activity/webhooks		✓
指定された webhook の URL に対して challenge response check (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	✓
[非推奨] 指定されたユーザーコンテキストおよびアプリケーションの購読を無効化します	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		✓

*_ 認証には、購読するユーザーの Access Tokens が必要です。 _ OAuth 1.0a のユーザーコンテキスト認証が必要なこれらの Endpoint では、リクエストを認証するために次の資格情報を提供する必要があります:

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

次の 3 つの Endpoint の場合、アプリケーションのコンテキスト内で書き込み操作を実行します（X のユーザーは関与しません）。したがって、提供すべき Access Tokens は、あなたの開発者用 App に属するものです。これらは developer portal のあなたの 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つの endpoint では、あなたのアプリケーションが X ユーザー（例：ダイレクトメッセージ）の代理として保護されたデータにアクセスできるようにするリクエストを行います。したがって、該当する購読ユーザーに属する Access Tokens を提供する必要があります。必要な Access Tokens は 3-legged OAuth フローで取得できます（OAuth 1.0a: how to obtain a user’s Access Tokens を参照）。これらの endpoint は上の表でアスタリスク（*）で示されています。

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 section 内、選択した開発者用 App の「App permissions」で変更できます。権限を変更した後は、App の認証情報を再生成する必要があります。

Account Activity API で利用可能なすべての endpoint の一覧（説明および認証実装例付きの cURL リクエスト例を含む）は、the API reference documentationで確認できます。追加情報については、Enterprise Account Activity API の利用開始に役立つ XDev のサンプル Web アプリとヘルパースクリプトをご覧ください。

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

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


説明	Endpoint	OAuth 1.0a (ユーザーコンテキスト)	OAuth 2.0 Bearer Token (アプリケーションのみ)
指定されたアプリケーションコンテキストに対して新しい webhook URL を登録	POST account_activity/webhooks	✓
指定されたアプリケーションのすべての URL とそれぞれの status を返す	GET account_activity/webhooks		✓
指定された webhook の URL に対して Challenge Response Check（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	✓
[非推奨] 提供されたユーザーコンテキストおよびアプリケーションの購読を無効化	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		✓

*_ 認証には、購読ユーザーの Access Tokens が必要です。 _ OAuth 1.0a のユーザーコンテキスト認証を必要とするこれらの Endpoint では、リクエストを認証するために次の認証情報を提供する必要があります:

Consumer Keys (API Key および Secret)
Access Tokens (Access Token および Secret)

以下の3つの Endpoint では、アプリケーションのコンテキスト内で書き込み操作を行います（X のユーザーは関与しません）。したがって、提供する必要がある Access Tokens はあなたの開発者用 App に属するものです。これらは developer portal のあなたの App の「Keys and tokens」タブから直接生成できます。

POST account_activity/webhooks: 指定されたアプリケーションのコンテキストに対して新しい webhook URL を登録します
PUT account_activity/webhooks/:webhook_id: 指定された webhook の URL に対して CRC（チャレンジレスポンスチェック）を実行します
DELETE account_activity/webhooks/:webhook_id: webhook を削除します

一方、次の 3 つの endpoint では、アプリケーションが X ユーザー（例: ダイレクトメッセージ）に代わって保護された data にアクセスするリクエストを行います。したがって、該当する購読ユーザーに属する Access Tokens を提供する必要があります。必要な Access Tokens は 3-legged OAuth フローを使用して取得できます（OAuth 1.0a: how to obtain a user’s Access Tokens を参照）。これらの endpoint は上の表でアスタリスク（*）で示されています。

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 で利用可能なすべての endpoint の一覧（関連する説明および認証実装例を含む cURL リクエスト例）は、the API reference documentationにあります。追加情報については、Enterprise Account Activity API を使い始める際に、XDev のサンプル Web アプリとヘルパースクリプトをご確認ください。

リトライ

Enterprise Account Activity API の Enterprise ティアの利点の一つは、webhook イベントに対するリトライ機構です。HTTP 200 の「success」レスポンスコードが受信されない場合、X サーバーはリトライを開始し、5分間に最大3回まで webhook イベントを再送します。この webhook イベントのリトライサービスは、ネットワーク障害発生時やクライアント側のサービス中断・デプロイ時の信頼性確保とイベント復旧に寄与します。

リトライとは？

Account Activity API には、クライアントの Web アプリがアカウントアクティビティの webhook イベントに対して「成功」を示す 200 応答を返さない場合にリトライする機能があります。クライアント側でイベントの受信成功が確認できない場合、X はそのイベントが受信されなかったものと見なします。非 200 の応答が返された場合、3 秒以内に応答がない場合、またはまったく応答がない場合には、リクエストを再試行し、その接続を 3 秒間開いたままにします。つまり、こちらがあなたの webhook URL に送信しようとしているアクティビティに対し、2 回の試行の中で合計およそ 5 秒以内に応答すれば受信が確認されます。サーバーが応答しない、または一時的なエラーを返す場合には、5 分間リトライを継続します。検証の確認のためのリトライ試行は合計 3 回です。これにより、すべての webhook イベントを確実に受信できるよう冗長性とフェイルセーフが担保されます。なお、リトライが発生しているサブスクリプションでは、購読中のすべてのユーザーに関するあらゆるアクティビティについて、リトライされたイベントが配信されます。これら 8 回の試行以内に検証が確認されない場合、当該アクティビティは Account Activity API からは取得できなくなります。

再試行のタイムライン

Account Activity API は、200 応答が受信されるまで、5 分間のあいだに最大 3 回まで再試行します。詳細は以下の表をご参照ください。約 5 分を過ぎると、そのアクティビティは Account Activity API から再送できません。取り逃した data を収集するには、X の他の endpoint を使用する必要があります。たとえば、search APIs を使用して、関連する Posts、リツイート、Quote Tweets、メンション、返信を取得できます。取り逃したダイレクトメッセージは、この endpointで取得できます。

リトライのタイムライン


アクティビティが作成され、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 の試行を停止します。クライアントは他の X の endpoint を使用して data を復旧する必要があります。

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

オブジェクト	詳細
for_user_id	該当イベントに関連する、購読中のユーザーサブスクリプションを識別します。
is_blocked_by	（条件付き）他のユーザーが購読対象のユーザーをメンションした場合にのみ表示されます。Post のメンションイベントで true のときに含まれます。
source	アクティビティを実行しているユーザー。例: フォロー、ブロック、ミュートしているユーザーが source ユーザーです。
target	アクティビティの対象となるユーザー。例: フォロー、ブロック、ミュートされているユーザーが target ユーザーです。

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

メッセージタイプ	詳細
tweet_create_events	サブスクリプションユーザーが行う、またはそのユーザーに対して行われる以下のアクションに伴う Post ステータスのペイロード: Posts、リツイート、返信、@メンション、QuoteTweets、Quote Tweets のリツイート。
favorite_events	ユーザーと対象を含む Favorite（like）イベントのステータス。
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	コンプライアンス維持を容易にするための、削除された Posts の通知。

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

tweet_create_events（Posts、リツイート、返信、引用Tweet）

{
	"for_user_id": "2244994945",
	"tweet_create_events": [
	  {
		<Tweetオブジェクト>
	  }
	]
}

tweet_create_events (@メンション)

{
	"for_user_id": "2244994945",
	"user_has_blocked": "false",
	"tweet_create_events": [
	  {
		<Tweet オブジェクト>
	  }
	]
}

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オブジェクト>
		},
		"user": {
			<ユーザーオブジェクト>
		}
	}]
}

follow_events

{
	"for_user_id": "2244994945",
	"follow_events": [{
			"type": "follow",
			"created_timestamp": "1517588749178",
			"target": {
				<ユーザーオブジェクト>
			},
			"source": {
				<ユーザーオブジェクト>
			}
		]
	}
}

unfollow_events

{
	"for_user_id": "2244994945",
	"follow_events": [{
			"type": "unfollow",
			"created_timestamp": "1517588749178",
			"target": {
				<ユーザーオブジェクト>
			},
			"source": {
				<ユーザーオブジェクト>
			}
		]
	}
}

block_events

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "block",
		"created_timestamp": "1518127020304",
		"source": {
			<ユーザーオブジェクト>
		},
		"target": {
			<ユーザーオブジェクト>
		}
	}]
}

unblock_events

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "unblock",
		"created_timestamp": "1518127020304",
		"source": {
			<ユーザーオブジェクト>
		},
		"target": {
			<ユーザーオブジェクト>
		}
	}]
}

mute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "mute",
		  	"created_timestamp": "1518127020304",
			"source": {
				<ユーザーオブジェクト>
			},
			"target": {
				<ユーザーオブジェクト>
			}
		}
	]
}

unmute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "unmute",
		  	"created_timestamp": "1518127020304",
			"source": {
				<ユーザーオブジェクト>
			},
			"target": {
				<ユーザーオブジェクト>
			}
		}
	]
}

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": "日中はXでデータ、夕暮れ時はデザイン",
			"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": "分身 - X PE 意見は個人的なもの",
			"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 分から配信が始まり、最後の 1 分が配信されるまで、（可能な限り）時系列で継続します。完了時点で、Replay はジョブ完了イベントを webhook に送信します。アクティビティは時系列で配信されるため、開始時刻付近に一致する結果が少ない、または存在しない場合、最初の結果が配信されるまでに一定の待ち時間が発生する可能性があります。

制限事項

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

データの可用性とタイプ

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

移行の概要

Site Streams、User Streams、ならびに Account Activity API - DM Only の標準ベータ版は 2018 年に提供終了しました。これらの製品をご利用の方は、必ず Account Activity API の premium または enterprise 版へ移行してください。従来のダイレクトメッセージ endpoint も提供終了しました。これらの endpoint をご利用の方は、新しい DM endpoint への移行、または Account Activity API の premium 版または enterprise 版への移行を必ず行ってください。 詳細はこの告知をご確認ください。 これらの変更の影響を受ける endpoint は次のとおりです:

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

同等のアクセスを提供し、ダイレクトメッセージでは追加機能も備えた新しい endpoint とサービスをご利用いただけます:

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

これらの新しい endpoint とサービスへの円滑な移行を支援するため、2 つの移行ガイドを用意しています:

User Streams および Site Streams から新しい webhook ベースのサービスへ移行する方向けの Account Activity API 移行ガイド
ダイレクトメッセージの REST endpoint 間を移行する方向けの Direct Message 移行ガイド

さらに、Account Activity API と始め方に関する動画シリーズも用意しています。最後に、理解を深めてすぐに始められるよう、コードサンプルも提供しています:

Account Activity Dashboard は、Account Activity API を使い始めるためのヘルパースクリプトを備えたサンプルの Node.js ウェブアプリです。
SnowBot は、Account Activity API と REST ダイレクトメッセージ endpoint を使用するサンプルのチャットボットです。Ruby で記述され、Sinatra ウェブアプリフレームワークを使用し、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 endpoint からの移行に関するガイダンスは、Direct Message 移行ガイドをご参照ください。

変更点の概要

Account Activity API は、User Streams や Site Streams のような stream 接続ではなく、webhook を通じて、認証済みかつサブスクライブ済みのアカウント向けイベントを配信します。

廃止予定の API

GET user GET site（以下の制御 stream を含む: 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 とは動作が異なります。webhook を使って data を受信できるよう、Web アプリを変更する必要があります。webhook の詳細はこちらをご覧ください。 利用可能なデータ: もう一つの重要な相違点は、配信されるデータに関する点です。X は、X 上であなたがフォローしているユーザーからのイベント（いわゆるホームタイムライン）を今後は送信しません。これは意図的な変更であり、今後変更する予定はありません。 信頼性: stream と異なり、webhook では配信の確認が可能で、webhook の URL に到達しなかった POST されたアクティビティの再試行も行えます。これにより、一時的な切断やダウンタイムがあっても、該当するすべてのアクティビティを App が受信できているという確実性が高まります。

新機能

Account Activity API には多数の新機能があり、特に重要なのは、これまでのストリーミングではなく webhook 経由で data が配信されるようになった点です。webhook にはストリーミングに比べ多くの利点があり、なかでも顕著なのは速度と信頼性です。API は、利用可能になり次第、JSON イベントとして data を送信するため、アクティブな接続の維持や endpoint のポーリングは不要になります。これにより冗長化機能の必要性が抑えられ、全体的な効率が向上します。webhook の詳細は技術ドキュメントをご覧ください。

ユーザー購読の管理

Account Activity API は、1 つの登録済み webhook に対して複数の購読を設定できます。これにより、Site Streams のアーキテクチャと同様に、webhook を使って複数ユーザーの購読アクティビティを同一の宛先に配信できます。これにより、購読上限に関わる購読の管理・追跡を、webhook 接続とは切り離して行えます。さらに、単一または少数の購読から、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: developer portal での X app のセットアップを確認する User Streams または Site Streams に現在使用されている X app は、developer portal 内で所有ユーザーに対して一覧表示されます。この X app は Account Activity API にも利用でき、そのアプリケーションの認可済みユーザーを引き継げます。新しい app を作成し、必要に応じてユーザーにこの新しい app への再認可を行ってもらうことも可能です。企業の代理として新しい app を作成する場合は、企業の X @handle アカウントで app を作成することを推奨します。

X app ページの permissions タブで「Read, Write and Access direct messages」を有効にします。 *注: これらの設定変更は遡及適用されません。すでに認可済みのユーザーは、認可時点の設定を保持します。あるユーザーがまだ読み取り、書き込み、ダイレクトメッセージへのアクセスを許可していない場合は、そのユーザーにアプリケーションを再認可してもらう必要があります。
X Sign-in と、X API におけるユーザーコンテキストの仕組みに不慣れな場合は、Obtaining Access Tokens を確認してください。
「Keys and Tokens」タブの下部で、X app 所有者の access tokens を生成します。同じタブで、Consumer Key、Consumer Secret、Access Token、Access Token Secret を控えておいてください。API を使用する際に必要になります。
application-only API メソッド用に、Consumer Key と Consumer Secret を使用して Bearer Token を生成します。

ステップ 3: Webhook のセットアップと構成

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

ステップ 4: Webhook セットアップの検証

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

- webhook の所有者が Web アプリの所有者であることを検証するためにチャレンジレスポンスチェックを要求します。 - 各 POST リクエストにシグネチャヘッダーを付与し、Web アプリ側で送信元を検証できるようにします。

あなたが Web アプリおよび webhook URL の所有者であることを検証するため、X は Challenge Response Check (CRC) を実行します。これは循環冗長検査（cyclic redundancy check）と混同しないでください。
crc_token という名前のパラメータを含む GET リクエストが、あなたの webhook URL に送信されます。endpoint は、crc_token と app の Consumer Secret から作成される、base64 エンコードされた HMAC SHA-256 の hash である 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 への移行（control streams を使用）:

次のリクエストで 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	サブスクリプションユーザーが行った、またはサブスクリプションユーザーに対して行われた次のアクションに関する Post ステータスのペイロード：Posts、リツイート、返信、@メンション、QuoteTweets
favorite_events	ユーザーと対象を含むお気に入り（like）イベントのステータス。
follow_events	ユーザーと対象を含むフォローイベント。
block_events	ユーザーと対象を含むブロックイベント。
mute_events	ユーザーと対象を含むミュートイベント。
direct_message_events	ユーザーと対象を含むダイレクトメッセージのステータス。
direct_message_indicate_typing_events	ユーザーと対象を含むダイレクトメッセージの入力中イベント。
direct_message_mark_read_events	ユーザーと対象を含むダイレクトメッセージの既読イベント。

非推奨となったstreamingメッセージtype


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

廃止されたイベントタイプ


説明	イベント名	送信元	送信先	対象オブジェクト
ユーザーがPostを削除する	delete	現在のユーザー	現在のユーザー	Post
フォロー中のユーザーがPostを削除する	delete	フォロー中のユーザー	フォロー中のユーザー	Post
ユーザーがPostのお気に入りを解除する	unfavorite	現在のユーザー	Postの作者	Post
ユーザーのPostがお気に入り解除される	unfavorite	お気に入り解除したユーザー	現在のユーザー	Post
ユーザーが誰かのフォローを解除する	unfollow	現在のユーザー	フォロー中のユーザー	Null
ユーザーがListを作成する	list_created	現在のユーザー	現在のユーザー	List
ユーザーがListを削除する	list_destroyed	現在のユーザー	現在のユーザー	List
ユーザーがListを編集する	list_updated	現在のユーザー	現在のユーザー	List
ユーザーが誰かをListに追加する	list_member_added	現在のユーザー	追加されたユーザー	List
ユーザーがListに追加される	list_member_added	追加したユーザー	現在のユーザー	List
ユーザーが誰かをListから削除する	list_member_removed	現在のユーザー	削除されたユーザー	List
ユーザーがListから削除される	list_member_removed	削除したユーザー	現在のユーザー	List
ユーザーがListを購読する	list_user_subscribed	現在のユーザー	Listの所有者	List
ユーザーのListが購読される	list_user_subscribed	購読したユーザー	現在のユーザー	List
ユーザーがListの購読を解除する	list_user_unsubscribed	現在のユーザー	Listの所有者	List
ユーザーのListの購読が解除される	list_user_unsubscribed	購読解除したユーザー	現在のユーザー	List
ユーザーがプロフィールを更新する	user_update	現在のユーザー	現在のユーザー	Null
ユーザーが非公開設定を更新する	user_update	現在のユーザー	現在のユーザー	Null

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

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

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

変更点の概要

以下のDM endpointを引き続き使用している場合は、新しいendpointへ移行する必要があります。

廃止予定のendpoint	移行先の新しいendpoint
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

新機能

新しいダイレクトメッセージ API endpoint は、複数の新機能に対応し、過去のダイレクトメッセージへのアクセス性が向上しています。新機能には次が含まれます：

メディア添付（画像、GIF、動画）に対応。
事前定義されたオプションリストで、ユーザーに構造化された返信を促せる機能。
過去のダイレクトメッセージに最大30日間アクセス可能。

新しいダイレクトメッセージ機能の一覧および追加の新規 API endpoint については、技術ドキュメントを参照してください。

差分と移行時の考慮事項

新しい API endpoint は従来のものとは大きく動作が異なります。endpoint の URL を更新するだけでは、アプリケーションでエラーが発生します。移行にあたりアプリケーションを更新する際は、以下を考慮してください。

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

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

{
      "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": "Blue Bird",
          "entities": {
            "hashtags": [],
            "symbols": [],
            "urls": [],
            "user_mentions": [],
          },
          "quick_reply_response": {
            "type": "options",
            "metadata": "external_id_2"
          },
          "attachment": {
            "type": "media",
            "media": {
             ...
            }
          }
        }
      }

概要

完全に新しい Direct Message オブジェクト構造。
ユーザーオブジェクトの簡素化。
新しい情報の提供（クイックリプライの応答、添付ファイルなど）。

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

POST direct_messages/events/new は、ダイレクトメッセージ送信のための代替手段です。この endpoint における最大の違いは、すべての情報が個別の 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 endpointで行えるようになりました: GET direct_messages/events/list。この新しいendpointの大きな変更点は、送信済みと受信済みのメッセージの両方を新しいものから古いものへ（時系列の逆順）で返すことです。これにより会話の再構築が容易になります。ただし、送信のみ、または受信のみを取得したい場合は、sender_id プロパティを参照してレスポンスを後処理する必要があります。ページネーションは、ダイレクトメッセージのIDではなくカーソル値に基づく方式になりました。各レスポンスには cursor プロパティが返されます。GET direct_messages/events/list は、過去30日間のメッセージを、30日間にどれだけメッセージが存在していても最大30日分まで返します。カーソルが返されない場合は、これ以上返すメッセージがないことを意味します。GET direct_messages/events/show による個別のダイレクトメッセージへのアクセス方法は同じですが、返されるダイレクトメッセージオブジェクトの構造は前述のとおり異なります。最後に、ダイレクトメッセージへのリアルタイムアクセスは、Account Activity API の webhook を介して提供されます。User Streams または Site Streams からの移行については、Account Activity API の移行ガイドを参照してください。

要約

送信・受信メッセージが同一のendpointで返されるようになりました。
最大30日分のメッセージが返されます。
カーソルベースのページネーション。
webhook経由でのダイレクトメッセージへのリアルタイムアクセス。

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

ダイレクトメッセージは、DELETE direct_messages/events/destroy で削除できるようになりました。インターフェースはほぼ同じで、削除対象のメッセージのIDが必要です。主な違いは、この endpoint が POST リクエストではなく DELETE リクエストを要求する点です。削除されたダイレクトメッセージが公式の X クライアントにどのように反映されるかは、これまでと変わりません。ダイレクトメッセージは、指定されたユーザーの context のインターフェースからのみ削除されます。会話の他のメンバーは引き続きそのダイレクトメッセージにアクセスできます。

概要

ダイレクトメッセージを削除するには、そのidが必要です。
新しいendpointでは、DELETEリクエストが必要です。
削除されたダイレクトメッセージの公式Xクライアントでの反映方法は、これまでどおりです。

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

よくあるご質問

一般

Account Activity API を使用する利点は何ですか？ Account Activity API は webhook を使用します。これは、streaming API と異なり、こちらから情報を送信するために常時オープンな接続を維持しておく必要がないことを意味します。Webhook は REST API とも異なり、目的のデータを得るために 15 分ごとに何百回もこちらへポーリングする必要がありません。イベント発生時にデータを配信するため、ユーザーとあなたの App 間の効率が向上します。 Account Activity API には次の利点があります:

スピード: X のスピードでデータを配信します。
シンプルさ: 単一の webhook 接続で、アカウントのすべてのイベントを配信します。API で配信されるアクティビティには、Posts、@mentions、replies、リツイート、Quote Tweets、Retweets of Quote Tweets、likes、送信済みダイレクトメッセージ、受信ダイレクトメッセージ、follows、blocks、mutes が含まれます。
スケール: イベント上限によるレートリミットに縛られることなく、管理対象アカウントのすべてのアクティビティを受信できます。

Account Activity API は premium sandbox、premium paid、enterprise の各オファリングとして提供されており、監査・責任対応機能や追加機能のためにアカウント数が増えても必要に応じてスケールできます。開始するには、GitHub からサンプルコードのスニペットをダウンロードしてください。 どのプロダクト階層が自分に最適かをどのように判断すればよいですか？ Premium オプションと Enterprise オプションの違いについては、Account Activity API Overview のページをご覧ください。 Premium 環境と Enterprise webhook の違いは何ですか？ 違いはありません。各 Premium 環境にはそれぞれ独自の webhook_id があります。 Account Activity API 用に開発・ステージング・本番環境が必要です。可能ですか？ はい。有料ティア（Paid Premium および Enterprise）では、複数の webhook URL を登録し、API メソッドで環境ごとにサブスクリプションを個別に管理できます。さらに、複数のクライアントアプリを allowlist に追加して、現在の認可済みユーザーの権限を維持できます。 Account Activity API のセットアップに関するステップバイステップのガイドはありますか？ もちろんあります。

これから始める場合は、Getting started with webhooks ガイドをご覧ください。
X Dev サポート付きスクリプトに沿って進めてください:
- Account Activity API dashboard: webhook イベントを表示する Node の Web アプリ。
- SnowBot chatbot: Account Activity と Direct Message APIs 上に構築された Ruby の Web アプリ。このコードベースには、Account Activity API の webhook 設定を支援するscript が含まれます。

システムが一定期間ダウンした場合に、データを復旧する方法はありますか？ 有料ティア（Paid Premium および Enterprise）では、当社システムが 4 時間にわたり複数回、アクティビティの送信を再試行します。4 時間以内にあなたのシステムが応答しない場合、そのアクティビティは失われ、7 日以内に他の REST endpoints を使用してデータを復旧する必要があります。異なる webhook や環境を Account Activity Replay API のような冗長化手段として活用し、いずれかのシステムがダウンしてもアクティビティを取り逃さないようにすることをおすすめします。 Account Activity API ではどの認可方式を使用する必要がありますか？ Account Activity API に必要な認可方式は、API reference pages の各メソッドで説明しています。X の認証をこれから始める場合は、this section をご覧ください。 challenge-response check (CRC) とは何ですか？ Account Activity API のチャレンジレスポンスチェックは、Account Activity API のアクティビティが正しい開発者に送信されていることを担保するためのセキュリティ機能です。これは、受信している data が X から送られていることを開発者が確認する用途にも使用できます。X は、webhook URL が最後に検証されてから24時間ごとに、自動的に CRC をあなたの webhook URL に送信します。検証状態を維持するには、システムは3秒以内に有効なレスポンスを返す必要があります。詳細は Securing webhooks のページをご覧ください。 webhook URL が即座に無効化されるケースはありますか？ 次のいずれかが発生した場合、webhook を即座に無効とマークします。

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

相互にやり取りしているユーザーを購読している場合、アクティビティが重複して届くことはありますか？ はい。Web アプリがユーザー A とユーザー B に対して有効な購読を持ち、ユーザー A が Post でユーザー B に言及した場合、登録済みの webhook には2つの POST アクティビティが送信されます。各アクティビティには、どの購読に属するかを示す “for_user_id” の指標が含まれます。自分の webhook への購読を作成する際、次の endpoint の /all/ 部分を他のアカウントアクティビティのデータオブジェクトに置き換えて、API が配信するアクティビティを限定できますか？POST https://api.x.com/1.1/account_activity/all/:env_name/subscriptions.json いいえ、できません。現時点では、提供しているのは /all/ プロダクトのみです。 ユーザーからダイレクトメッセージの権限を要求せずに Account Activity API を使用する方法はありますか？ 現時点では、この API でダイレクトメッセージのアクティビティを「フィルタリング」する方法がないため、ダイレクトメッセージの権限が必要です。 Account Activity API の無料版はありますか？ はい、無料のティアとしてサンドボックス版を提供しています。サンドボックスオプションは、webhook は1つ、購読は最大15件に制限されています。サンドボックスオプションの詳細はドキュメントをご覧ください。 購読ユーザーに言及した Post のリツイートを取得するために Account Activity API を使用できますか？ 残念ながら、これはこの API が配信するアクティビティには含まれていません。これには Streaming API の使用をお勧めします。 tweet_create_event が表す可能性のあるアクティビティタイプは何ですか？ tweet_create_event のペイロードは以下の場合に送信されます。購読ユーザーが次のいずれかのアクションを実行した場合:

Post を作成
リツイート
Post に返信

他のユーザーが次のいずれかを行った場合:

購読ユーザーに @メンション* する
購読ユーザーが作成した Tweet を引用する

*注: Account Activity API は、購読ユーザーが X から通知を受け取り、かつそのイベントを公開範囲で確認できる場合にのみイベントを配信します。つまり、言及されたアカウント（@userA）が保護されたアカウント（@userB）をフォローしている場合、UserA は UserB が自分に言及したことの通知を受け取ります。UserA が UserB をフォローしていない（かつ UserB に承認されていない）場合、UserA は通知を受け取らず、そのため @userA が購読していても tweet_create_event は AAA 経由で送信されません。 ブロックしたユーザーが購読ユーザーに言及した場合、どのように識別できますか？ JSON レスポンスのトップレベルに boolean フィールド user_has_blocked が表示され、「true」または「false」のいずれかに設定されます。このフィールドは Post のメンションでのみ公開されます。 Enterprise 自分の App を allowlist に追加する、またはすでに allowlist にあるかを確認するにはどうすればよいですか？ Enterprise API を介したアクセスのために許可リストに追加したX appsを管理するには、App の id を添えてアカウントマネージャーにご連絡ください。App の id は、developer portal の”Apps”ページに移動すると確認できます。 webhook を3件利用できる場合、Enterprise 用に登録した各 App で3件ずつの webhook を使用できますか？ webhook の上限は App レベルではなくアカウントレベルで設定されています。webhook を3件利用でき、Enterprise 用に登録した App が2つある場合、1つの App に2件、もう一方の App に1件の webhook を使用できますが、各 App に3件ずつは使用できません。 Account Activity Replay API を使用して再配信されるイベントの種類を指定できますか？ 再生するイベントの種類は指定できません。指定した日時の範囲内で配信されたすべてのイベントが再生されます。 アプリケーションが Account Activity Replay API のイベントの取り込みに失敗した場合、再試行はありますか？ いいえ、再試行はありません。アプリケーションが Account Activity Replay API によって送信されたイベントの取り込みに失敗した場合、同一期間に対して別の Replay ジョブを送信し、取りこぼした Replay イベントの再配信を試みることができます。 部分的成功の完了イベントを受け取った場合はどうすればよいですか？ 受信したイベントのタイムスタンプを控え、未受信のイベントに対して別の Replay ジョブをリクエストすることをお勧めします。 同時に実行できる Account Activity Replay API ジョブは何件ですか？ 1つの webhook につき同時に実行できる Account Activity Replay API ジョブは1件のみです。 Account Activity Replay API のイベントと、webhook に配信されるリアルタイムの本番イベントをどのように区別できますか？ Account Activity Replay API は常に過去のイベントを配信するため、イベントのタイムスタンプに基づいてリアルタイムの本番イベントと区別できます。 アプリケーションがドロップまたは見逃したアクティビティの再配信に、Account Activity Replay API をどれくらい早く使い始められますか？ アクティビティは作成から約10分後に再配信が可能になります。

エラー対応ガイド

コード 32

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

Enterprise - 使用しているコンシューマーキーおよび Access Tokens が、Enterprise 製品の利用に登録された X App に属していることを確認してください。コンシューマーキーや Access Tokens をお持ちでない場合、または X App を許可リストに追加する必要がある場合は、アカウントマネージャーにご連絡ください。
ユーザー context で認証する場合は、oauth nonce、oauth_signature、oauth_timestamp を適切に含めてリクエストを認可していることを確認してください。
Access Tokens に適切な権限レベルがあることを確認してください。
- App ダッシュボードの「Keys and tokens」タブで、Access Tokens のpermission levelが「Read, write, and direct messages」になっていることを確認してください。
- トークンの権限レベルがこれより低い場合は、「Permissions」タブでアクセス権限を「Read, write, and direct messages」に変更し、その後「Keys and tokens」タブから Access Tokens とシークレットを再生成してください。
URL の形式が正しいことを確認してください。
- :env_name は大文字と小文字を区別します。

コード 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 セクションをご覧ください。

コード 214 - CRC の GET リクエストで高いレイテンシーが発生しています。webhook は 3 秒未満で応答する必要があります。

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

コード 214 - CRC の GET リクエスト中に 200 以外のレスポンスコード（例：404、500 など）

サーバーが停止しています。サーバーが正常に稼働していることを確認してください。

コード 214 - 既に作成されたリソースが多すぎます。

Enterprise - 利用可能な webhook をすべて使い切っています。登録済みの各 App で GET webhooks endpoint を使用し、webhook の配布先を特定してください。

コード 261 - アプリケーションは書き込みアクションを実行できません。

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

Account Activity API リファレンス索引


目的	Enterprise
webhook の URL を登録／webhook_id を生成	POST webhooks
すべての webhook URL とそのステータスを返す	GET webhooks
チャレンジレスポンスチェックを手動で実行	PUT webhooks/:webhook_id
アカウントのイベントに App を購読登録	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

Enterprise Account Activity API

POST account_activity/webhooks

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

リソースURL

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

リソース情報


レスポンス形式	JSON
認証が必要	はい（ユーザー context - すべての consumer と access tokens）
レートリミット	はい
リクエスト数 / 15分ウィンドウ（ユーザー認証）	15
Tweet 編集のサポート	すべての Tweet オブジェクトに、Tweet の編集履歴を示す Tweet 編集 metadata が含まれます。詳細は”Tweet edits の基本”ページおよび「Tweet edits（編集）」ページ（/x-api/enterprise-gnip-2.0/fundamentals/edit-tweets）を参照してください。

パラメータ


url（必須）	コールバック用 endpoint のエンコード済み 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 コード	メッセージ
200	webhook の URL は指定された App に登録されています
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": "リソースが作成上限に達しています。"
        }
      ]
    }

GET account_activity/webhooks

指定したアプリケーションに対するすべてのURLとそのstatusesを返します。 URLが日次の検証に失敗した場合、そのURLは無効としてマークされます。URLを再度有効にするには、更新用のendpointを呼び出してください。

リソースURL

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

リソース情報


レスポンス形式	JSON
認証の要否	必要（アプリケーションのみ・Bearer Token）
レートリミット	あり
リクエスト数 / 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）を実行します。チェックが成功すると、ステータスを valid に設定して webhook を再有効化し、204 を返します。

リソースURL

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

リソース情報


レスポンス形式	JSON
認証が必要	はい（ユーザー context - すべてのコンシューマーおよび Access Tokens）
レートリミット	あり
リクエスト数 / 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	Message
34	webhook が存在しない、または別の X App に関連付けられています。
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

指定したユーザーコンテキストに対して、指定したAppをすべてのメッセージタイプにおけるすべてのイベントの受信対象として登録します。有効化後は、リクエスト元ユーザーに関するすべてのイベントが、POSTリクエストでアプリケーションのwebhookに送信されます。サブスクリプションは現在、お客様のアカウント設定に基づき制限されています。追加のサブスクリプションが必要な場合は、アカウントマネージャーまでご連絡ください。

リソースURL

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

リソース情報


レスポンス形式	JSON
認証が必要	はい（3-legged OAuth（ホワイトリスト登録済みの Consumer Key と購読ユーザーの access token））
レートリミット	あり
リクエスト数 / 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 App に関連付けられています。
348	クライアントアプリケーションには、このユーザーの webhook サブスクリプションにアクセスする権限がありません。

GET account_activity/subscriptions/count

この endpoint は、あなたのアカウントで現在アクティブなサブスクリプションの件数を返します。/count endpoint の利用にはアプリケーション専用の OAuth が必要です。そのため、ユーザー context ではなく Bearer Token を使用してリクエストしてください。

リソース URL

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

リソース情報


レスポンス形式	HTTP レスポンスコード
認証	必要（アプリケーションのみ・Bearer Token）
レートリミット	あり
リクエスト数 / 15分ウィンドウ（アプリケーション認証）	15

HTTPレスポンスコード


コード	メッセージ
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"
    }

エラーメッセージ

コード	メッセージ
32	認証できませんでした。

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "認証に失敗しました。"
        }
      ]
    }

GET account_activity/webhooks/:webhook_id/subscriptions/all

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

リソースURL

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

リソース情報


レスポンス形式	JSON
認証が必要	はい（3-legged OAuth — ホワイトリスト登録済みの consumer key と購読ユーザーの access token）
レートリミット	あり
リクエスト数 / 15分間（ユーザー認証）	500

パラメータ


webhook_id (必須)	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 endpoint はアプリケーション専用の OAuth（App-only OAuth）を必要とするため、リクエストはユーザーコンテキストではなく Bearer Token を用いて行ってください。

リソース URL

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

リソース情報


応答形式	HTTP レスポンスコード
認証の要否	要（アプリケーションのみ — Bearer Token）
レートリミット	あり
リクエスト数 / 15分ウィンドウ（アプリケーション認証）	50

パラメータ


webhook_id（必須）	webhook の id。リソースパスで定義されます。

HTTP レスポンスコード

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"
      }]
    }

エラーメッセージ

コード	メッセージ
32	認証に失敗しました。

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "認証に失敗しました。"
        }
      ]
    }

DELETE account_activity/webhooks/:webhook_id

指定したAppの設定からwebhookを削除します。webhookのidは、GET /1.1/account_activity/webhooks を呼び出すことで取得できます。

リソースURL

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

リソース情報


レスポンス形式	JSON
認証が必要	はい（user context — すべてのコンシューマーおよび Access Tokens）
レートリミット	はい
リクエスト/15分ウィンドウ（ユーザー認証）	15

パラメータ


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

リクエストの例

    $ 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 (非推奨)

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

リソースURL

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

リソース情報


レスポンス形式	JSON
認証が必要	はい（3-legged OAuth — ホワイトリスト登録済みの consumer key と購読ユーザーの access token）
レートリミット	はい
リクエスト数 / 15分ウィンドウ（ユーザー認証）	500

パラメータ


webhook_id（必須）	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 に送信されなくなります。なお、この endpoint にはアプリケーション専用の OAuth が必要なため、リクエストはユーザー context ではなく Bearer Token を使用して行ってください。

リソースURL

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

リソース情報


レスポンス形式	JSON
認証	必要（アプリケーションのみ・Bearer Token）
レートリミット	あり
リクエスト数 / 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

エラーメッセージ

コード	メッセージ
404	申し訳ありません、そのページは存在しません。- 指定されたユーザーidが実際には購読していない場合によく発生します。

Replay API

POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json ¶ リクエストで指定した日時ウィンドウの間に存在していたすべてのサブスクリプションを対象に、過去最大5日分のアクティビティ取得を要求します。webhook にアクティブなユーザーサブスクリプションがある場合、それらのイベントも同時に受信します。注: リプレイイベントの配信前に 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	はい（アプリのみ - Bearer Token）
Rate Limit	15分あたり5リクエスト。要求可能なリプレイジョブ数に現在、上限はありません。
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 以外のレスポンスの場合は、エラーを解消してから再試行してください。

ステータス	テキスト	エラーコード	説明	メッセージ
202	Accepted	N/A	リクエストは成功し、アクティビティが送信されます。	N/A
400	Bad Request	214	webhook が無効としてマークされています。	Webhook は無効としてマークされており、CRC チェックが必要です。
400	Bad Request	357	query パラメータがありません。	: queryParam は必須です。
400	Bad Request	358	ルートまたは query パラメータの形式が不正です。	パラメータを解析できません。
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 認証が失敗しました。	認証方法が無効です。アプリケーション専用認証を使用してください。
401	Unauthorized	61	クライアントはこのメソッドをリクエストする権限がありません。	クライアントはこのメソッドをリクエストする権限がありません。
403	Forbidden	200	クライアントに Replay が有効な Enterprise アカウントがありません。	Account Activity API の replay が有効な Enterprise アカウントが必要です。Enterprise アカウントをお持ちで、replay が有効になっていることを確認してください。
404	Not Found	34	存在しない webhook_id、または webhook_id と application_id の不一致。	Webhook が存在しないか、別の X アプリケーションに関連付けられています。
409	Conflict	355	進行中のリクエストがあり、別のリクエストを行う前に処理の完了を待つ必要があります。	この webhook ではリプレイジョブがすでに進行中です。
429	Too Many Requests	88	レートリミットに達しました（一定時間内のリクエスト数の上限に到達）	リクエストが多すぎます。API のリクエストレートを下げてください。
500	Internal Server Error	0	内部サーバーエラー。	内部サーバーエラー。
503	Service Unavailable	67	X の 1 つ以上の依存サービスが利用できません。	X サーバーエラー。指数バックオフ方式で再試行してください。

「ジョブが正常に完了しました」メッセージ

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

{
  "replay\_job\_status": {
    "webhook_id": "1234577122340233217",
    "job_state": "Complete",
    "job\_state\_description": "ジョブが正常に完了しました"
    "job_id": "1095098195724558337"
  }
}

「ジョブの完了に失敗しました」というメッセージ

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

{
  "replay\_job\_status": {
    "webhook_id": "123451374207332352",
    "job_state": "Incomplete",
    "job\_state\_description": "すべてのイベントの配信に失敗しました。リプレイジョブを再実行してください",
    "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"
}

概要

Posts

ユーザー

ダイレクトメッセージ

いいね

List

Spaces

コミュニティ

コミュニティノート

トレンド

メディア

使用方法

stream 接続

コンプライアンス

Enterprise v2

Likes Streams

GNIP 2.0

​動画シリーズ

​機能概要

​webhook と購読ユーザーを管理する

​webhook の管理:

​サブスクライブ済みユーザーの管理:

​参照記事

​Account Activity API の動画ウォークスルー

​webhook のはじめに

​1. X App を作成します。

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

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

​4. セットアップの検証

​webhook の保護

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

​CRC リクエストが発生するタイミング:

​レスポンス要件:

​言語別の HMAC ライブラリ：

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

​JSON レスポンスの例:

​その他の例:

​任意の署名ヘッダー検証

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

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

​推奨サーバー構成

​webhookとサブスクリプションの管理

​webhook の作成と変更

​webhook 設定管理 endpoint:

​webhook URL を更新するだけではいけないのはなぜですか？

​ユーザーサブスクリプションの追加と削除

​サブスクリプション管理 endpoints

​リトライ

​リトライとは？

​再試行のタイムライン

​リトライのタイムライン

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

​tweet_create_events（Posts、リツイート、返信、引用Tweet）

​tweet_create_events (@メンション)

​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

​Account Activity Replay API

​Account Activity Replay API の使用

​制限事項

​データの可用性とタイプ

​移行の概要

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

​変更点の概要

​廃止予定の API

​代替API

​相違点と移行時の考慮事項

​新機能

​ユーザー購読の管理

​移行手順

​以下の手順に従って、Site Streams API から Account Activity API へ簡単に移行してください

動画シリーズ

機能概要

webhook と購読ユーザーを管理する

webhook の管理:

サブスクライブ済みユーザーの管理:

参照記事

Account Activity API の動画ウォークスルー

webhook のはじめに

1. X App を作成します。

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

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

4. セットアップの検証

webhook の保護

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

CRC リクエストが発生するタイミング:

レスポンス要件:

言語別の HMAC ライブラリ：

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

JSON レスポンスの例:

その他の例:

任意の署名ヘッダー検証

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

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

推奨サーバー構成

webhookとサブスクリプションの管理

webhook の作成と変更

webhook 設定管理 endpoint:

webhook URL を更新するだけではいけないのはなぜですか？

ユーザーサブスクリプションの追加と削除

サブスクリプション管理 endpoints

リトライ

リトライとは？

再試行のタイムライン

リトライのタイムライン

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

tweet_create_events（Posts、リツイート、返信、引用Tweet）

tweet_create_events (@メンション)

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

Account Activity Replay API

Account Activity Replay API の使用

制限事項

データの可用性とタイプ

移行の概要

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

変更点の概要

廃止予定の API

代替API

相違点と移行時の考慮事項

新機能

ユーザー購読の管理

移行手順

以下の手順に従って、Site Streams API から Account Activity API へ簡単に移行してください

Account Activity ダッシュボード（Account Activity API サンプルアプリケーション）

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

非推奨となったstreamingメッセージtype

廃止されたイベントタイプ

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

変更点の概要

新機能

差分と移行時の考慮事項

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

概要

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

まとめ

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

要約

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

概要

よくあるご質問