2026年のMake.comとTwitter(X)の連携
Make.comのTwitter(X)アプリは2025年4月3日に姿を消し、それを使ったシナリオはすべて2025年5月30日に停止しました。現在MakeにXのデータを取り込むには、シナリオからHTTPモジュールでXデータAPIを呼び出します。
要点: MakeはXのAPI規約を理由にXアプリを廃止し、2026年11月時点でも復活していません。現在の読み取りはHTTP > Make a requestで行い、公式X APIは投稿1件$0.005を課金します。MakeでXを読むなら、Sorsa APIです。ApiKey のキーチェーン1つで、1リクエストあたり20投稿、1,000件あたり$0.07から、100回分の無料リクエストが付きます。
- エンドポイント
POST /search-tweets- 1ページの件数
- 1リクエストあたり20投稿
- 料金
- 1,000ツイートあたり$0.07から
#MakeのTwitter(X)アプリに何が起きたか
MakeのX(旧Twitter)アプリは、完全になくなりました。Makeは2025年4月3日にアプリ検索から外し、そのモジュールを使い続けたシナリオは2025年5月30日から失敗し始めました。Makeのリリースノート(新しいタブで開きます)が挙げる理由は、XのAPIポリシーの要件と料金の1つで、Makeはこれが顧客にとって「妥当な連携」を不可能にするとしています。
その後、復活したものはありません。日付で見るとこうなります。
| 日付 | Makeでの変更 |
|---|---|
| 2025年4月3日 | Xアプリがアプリ検索から消える。新しいXのシナリオは作れない |
| 2025年5月30日 | 既存のXのシナリオが停止。開くことはできるが、実行のたびに失敗する |
| 2026年1月19日 | Makeの通知が最後に更新される。方針の変更はなし |
| 2026年11月2日 | MakeのインテグレーションにXアプリはまだない(このガイドのために確認) |
2025年4月3日
- Makeでの変更
- Xアプリがアプリ検索から消える。新しいXのシナリオは作れない
2025年5月30日
- Makeでの変更
- 既存のXのシナリオが停止。開くことはできるが、実行のたびに失敗する
2026年1月19日
- Makeでの変更
- Makeの通知が最後に更新される。方針の変更はなし
2026年11月2日
- Makeでの変更
- MakeのインテグレーションにXアプリはまだない(このガイドのために確認)
Make(旧Integromat)は、Xに投稿していた顧客にはソーシャルメディア管理アプリを案内しており、Grokのモデルを使えるxAIアプリは影響を受けませんでした。どちらもXから投稿、プロフィール、フォロワーを読み取るものではありません。現在、Xのデータを読むには、MakeのHTTPアプリからリクエストを送ります。HTTPアプリは、REST APIを持つあらゆるサービスと通信できます。
このモジュールから公式X APIを呼び出すには、Xの開発者アプリ、ベアラートークンまたはOAuth接続、そして前払いクレジットが必要です。Xの料金ページ(新しいタブで開きます)によれば、投稿の読み取りは1件$0.005、ユーザーまたはフォロワーは1件$0.010で、従量課金は月間300万件の投稿読み取りが上限です。2026年11月22日からは、Xは各投稿の投稿者もユーザーの読み取りとして課金するため、投稿者つきの投稿は$0.015になります(Xの10月23日の通知(新しいタブで開きます))。
#Sorsa APIでMakeからXのデータを読む
Twitter(X)API兼スクレイピングツールであるSorsa APIは、APIキー1つと、すべてのMakeプランにすでにあるHTTPアプリで、この空白を埋めます。Makeのシナリオでツイート、メンション、フォロワーを読むなら、Sorsa APIを使ってください。1リクエストで20投稿または200フォロワー、2006年までさかのぼる検索、全プラン毎秒20リクエストで、Xの開発者アカウントも、更新が必要なOAuth接続も不要です。
手順では、最新の投稿を返すキーワード検索を作ります。以降のほかの作業は、同じキーチェーンとモジュールを、URLだけ変えて使い回します。
-
APIキーを取得する。 登録して、ダッシュボードからキーをコピーします。最初の100リクエストは無料で、カードは不要、有効期限もありません。
-
キーをキーチェーンに保存する。 HTTPアプリのMake a requestモジュールを追加し、Authentication typeをAPI keyに設定します。Credentialsの下でキーチェーンを作成し、Keyにキーを貼り付け、API key placementをIn the header、API key parameter nameを
ApiKeyに設定します。こうすると、キーはモジュールのフィールドに残らず、あとからKeysで更新できます。 -
モジュールをSorsa APIに向ける。 URLを
https://api.sorsa.io/v3/search-tweets、MethodをPOSTに設定します。 -
検索をJSONで送る。 Body content typeをapplication/JSON、Body input methodをJSON stringに設定し、2つのフィールドを持つ本文を入力します。
queryにはXの検索(演算子を含む)を、orderにはlatestかpopularを指定します。下のcurlは同じリクエストで、Makeに入れる前にクエリを試すのに便利です。Terminal curl -X POST "https://api.sorsa.io/v3/search-tweets" \ -H "ApiKey: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"query": "make.com lang:en -filter:retweets", "order": "latest"}' -
レスポンスをパースして、1回実行する。 Parse responseをYesにして、Run onceをクリックします。モジュールの出力のDataに、
tweets配列とnext_cursorが入り、以降のモジュールはそのフィールドをマッピングできます。Response200 OK { "tweets": [ { "id": "1985417630058127650", "full_text": "Rebuilt our launch tracker as a make.com scenario.", "created_at": "2026-11-02T08:41:19Z", "lang": "en", "likes_count": 18, "retweet_count": 2, "reply_count": 4, "view_count": 1290, "user": { "id": "1601177354291937280", "username": "scenario_builder_notes", "display_name": "Scenario Builder Notes", "followers_count": 2315 } } ], "next_cursor": "DAADDAABCgABG4V8kQ2W" }キーはキーチェーンに置き、URL、メソッド、JSONの本文、Parse responseで残りを設定します。
HTTPモジュールの後ろにFlow Control > Iteratorを追加し、ArrayをDataの下の tweets 配列に設定します。すると各投稿が、投稿者の完全なプロフィールを含む1つのバンドルとしてシナリオを流れるので、スプレッドシートの行やSlackのメッセージで、2回目のリクエストなしにハンドルとフォロワー数を表示できます。401はキーが誤っていること、403はキーがない、またはアカウントのリクエストを使い切ったことを意味します。
#Makeのシナリオごとに使うエンドポイント
Makeのどの作業も、Sorsa APIのエンドポイント1つに対応し、エンドポイントのメソッドによって、HTTPモジュールがそのページをどうたどるかが決まります。次の表は、Makeのシナリオで最もよく使うエンドポイントです。全45件の一覧はSorsa APIのエンドポイントにあります。
| Makeのシナリオ | エンドポイント | 送る内容 | 1リクエストあたり | Makeでのページ送り |
|---|---|---|---|---|
| キーワードまたはハッシュタグの検索 | POST /search-tweets(新しいタブで開きます) | query、order | 約20投稿 | Repeaterのループ |
| 1アカウントの投稿 | POST /user-tweets(新しいタブで開きます) | username | 約20投稿 | Repeaterのループ |
| ブランドのメンション | POST /mentions(新しいタブで開きます) | query(ハンドル)、min_likes、since_date | 約20投稿 | Repeaterのループ |
| XのListのフィード | GET /list-tweets(新しいタブで開きます) | list_id | 約20投稿 | 組み込みのページネーション |
| フォロワーのエクスポート | GET /followers(新しいタブで開きます) | username | 最大200フォロワー | 組み込みのページネーション |
キーワードまたはハッシュタグの検索
- 送る内容
query、order- 1リクエストあたり
- 約20投稿
- Makeでのページ送り
- Repeaterのループ
1アカウントの投稿
- 送る内容
username- 1リクエストあたり
- 約20投稿
- Makeでのページ送り
- Repeaterのループ
ブランドのメンション
- エンドポイント
- POST /mentions(新しいタブで開きます)
- 送る内容
query(ハンドル)、min_likes、since_date- 1リクエストあたり
- 約20投稿
- Makeでのページ送り
- Repeaterのループ
XのListのフィード
- エンドポイント
- GET /list-tweets(新しいタブで開きます)
- 送る内容
list_id- 1リクエストあたり
- 約20投稿
- Makeでのページ送り
- 組み込みのページネーション
フォロワーのエクスポート
- エンドポイント
- GET /followers(新しいタブで開きます)
- 送る内容
username- 1リクエストあたり
- 最大200フォロワー
- Makeでのページ送り
- 組み込みのページネーション
数分おきに実行するモニターで2ページ目が必要になることはまれです。2回の実行の間なら、1リクエストの最新の約20投稿でほとんどのキーワードをカバーできるからです。ページネーションが重要になるのは、過去分の取得とエクスポートで、次の節で設定します。
下のビルダーは、作業に合わせてモジュールを作ります。作業を選び、クエリ、ハンドル、ListのIDを入力すると、設定をコピーするか、HTTPモジュールとIteratorを含むブループリントをダウンロードできます。Makeで空のシナリオを開き、三点メニューからImport blueprintを選んでファイルを指定し、ApiKey ヘッダーにキーを貼り付けるか、モジュールを手順2のキーチェーンに切り替えてください。
HTTP > Make a request
- 認証タイプ(Authentication type)
- APIキー、ヘッダー名ApiKeyのキーチェーン
- URL
https://api.sorsa.io/v3/search-tweets- メソッド(Method)
POST- ボディ(Body)、JSON文字列
{"query": "make.com lang:en -filter:retweets", "order": "latest"}- レスポンスの解析(Parse response)
- はい
- ページネーション(Pagination)
- モジュールにはなし。追加ページはRepeaterループで
- イテレータの配列(Iterator array)
Data > tweets- リクエストあたり
- 約20投稿
{
"name": "Sorsa API: search-tweets to Iterator",
"flow": [
{
"id": 1,
"module": "http:ActionSendData",
"version": 3,
"parameters": {
"handleErrors": false,
"useNewZLibDeCompress": true
},
"mapper": {
"ca": "",
"qs": [],
"url": "https://api.sorsa.io/v3/search-tweets",
"gzip": true,
"method": "post",
"headers": [
{
"name": "ApiKey",
"value": "YOUR_API_KEY"
}
],
"timeout": "",
"useMtls": false,
"authPass": "",
"authUser": "",
"bodyType": "raw",
"serializeUrl": false,
"shareCookies": false,
"parseResponse": true,
"followRedirect": true,
"useQuerystring": false,
"followAllRedirects": false,
"rejectUnauthorized": true,
"contentType": "application/json",
"data": "{\"query\": \"make.com lang:en -filter:retweets\", \"order\": \"latest\"}"
},
"metadata": {
"designer": {
"x": 0,
"y": 0
}
}
},
{
"id": 2,
"module": "builtin:BasicFeeder",
"version": 1,
"parameters": {},
"mapper": {
"array": "{{1.data.tweets}}"
},
"metadata": {
"designer": {
"x": 300,
"y": 0
}
}
}
],
"metadata": {
"instant": false,
"version": 1,
"scenario": {
"roundtrips": 1,
"maxErrors": 3,
"autoCommit": true,
"autoCommitTriggerLast": true,
"sequential": false,
"confidential": false,
"dataloss": false,
"dlq": false,
"freshVariables": false
},
"designer": {
"orphans": []
}
}
}
インポート後、ApiKeyヘッダーにキーを貼り付けるか、モジュールをキーチェーンに切り替えてください。
Makeのドキュメントにあるブループリント形式に基づいています。インポート時にMakeがフィールドを拒否した場合は、設定一覧を見ながらモジュールを手動で設定してください。
#ページネーション:Makeでnext_cursorをたどる
Sorsa APIはカーソルでページを送ります。各レスポンスが次のページを指すトークン next_cursor を持ち、最後のページでは空で返ります。Makeがカーソルをたどる方法は、エンドポイントがそれをクエリ文字列とJSON本文のどちらで受け取るかによって変わります。
GETエンドポイント:HTTPモジュール組み込みのページネーション
現行のHTTPモジュールは、Token or cursor-basedのページネーションタイプで自動的にページを送り、カーソルをクエリパラメーターとして送ります。Sorsa APIのGETの一覧エンドポイントが読み取るのも、そこです。MakeのHTTPのドキュメント(新しいタブで開きます)にフィールドが載っています。/followers と /list-tweets では、次の値を設定します。
- Pagination type: Token or cursor-based。
- Items path: フォロワーなら
users、Listのフィードならtweets。 - Next page token/cursor path と Page token/cursor parameter name: どちらも
next_cursor。 - Page size parameter: 空欄。ページサイズはSorsa APIが決めるためです。
- Output formatとLimit: Array of items、そして1回の実行で返す最大件数(最大1万)。
フォロワー1万件のLimitなら、1リクエスト200件で50リクエストかかります。同じ設定が /follows、/verified-followers、/list-members、/list-followers でも使えます。
POSTエンドポイント:Repeaterのループ
検索、タイムライン、メンションはPOSTエンドポイントで、APIリファレンスの定義どおり next_cursor をJSON本文で受け取るため、組み込みのページネーションでは動かせません。次の5つのモジュールで動かせます。
-
繰り返す。 Flow Control > Repeaterを追加し、Repeatsを1回の実行で読む最大ページ数(たとえば10)に設定します。
-
カーソルを読む。
cursorという名前の変数について、Tools > Get variableを追加します。 -
終わりで止める。 その後ろにフィルターを置き、最初の繰り返し、または存在する
cursorを通します。 -
ページをリクエストする。 上の手順のHTTPモジュールを追加し、本文に
next_cursorを加えて、変数にマッピングします。最初のリクエストでは省くように、そのフィールドをMakeのif()関数で包みます。 -
次のカーソルを保存する。 Tools > Set variableを追加し、レスポンスの
next_cursorをcursorとして保存します。Variable lifetimeはOne executionにします。
最後のページのあとの繰り返しはフィルターで止まるので、Makeのクレジットは消費しますが、Sorsa APIのリクエストは消費しません。
知っておきたいこと
/search-tweets、/user-tweets、/mentionsでは、組み込みのページネーションを使わないでください。これはカーソルをクエリ文字列で送りますが、APIリファレンスはこれらのエンドポイントを、カーソルをJSON本文で受け取るものと定義しています。ページを送るにはRepeaterのループを使います。
#新しい投稿をGoogleスプレッドシートやSlackへ
Makeのシナリオは、キーワードに関する、または一連のアカウントの新しい投稿を、1件ずつ、重複なしで記録できます。必要なのは4つのモジュールで、HTTPモジュール、Iterator、フィルター、出力先です。MakeにはXの新規投稿のトリガーがなく、Sorsa APIにもWebhookはないので、シナリオがスケジュールでポーリングし、新しい投稿だけを通します。
-
スケジュールを設定する。 シナリオを一定間隔で実行するように設定します。たとえば15分ごと(Makeの既定)です。
-
最新の投稿を取得する。
POST /search-tweetsのHTTPモジュールで、orderをlatestにします。アカウントを監視するなら、from:演算子をORでつないで1つのクエリにします。数百のアカウントなら、公開のXのListに追加して、そのlist_idでGET /list-tweetsを呼びます。1リクエストで、最大5,000アカウントのListのフィードを読めます。 -
投稿を分割する。
tweets配列にIteratorを追加します。 -
新しい投稿だけを通す。 Iteratorの後ろのリンクにフィルターを設定します。
created_atが「実行時刻の16分前」より後であること。Makeでは addMinutes(now; -16) と書きます。余分な1分はスケジュールのずれを吸収し、フィルターはクレジットを消費しません。 -
書き込む、または送る。 Google Sheets > Add a rowまたはSlack > Create a messageを追加し、
full_text、user.username、created_at、idをマッピングします。
厳密に重複を避けるには、フィルターの後ろに投稿IDをキーとするData storeを追加します。Check the existence of a recordで、まだ保存されていない投稿だけを通し、行を書き込んだらAdd/replace a recordで記録します。IDは正確なテキストのキーとして照合してください。投稿IDは19桁で、数式の数値が正確に保持できる桁数を超えており、IDをテキストとして並べ替えると、桁数が異なる場合に「9」が「10」の後に来ます。
シート側の扱いは、TwitterデータをGoogleスプレッドシートにエクスポートのガイドで解説しています。列のレイアウト、大きなフォロワーのリスト、Makeを使わないApps Scriptの方法です。数秒以内のアラートや大規模なキーワード監視は、リアルタイムTwitter監視を参照してください。
#MakeでのXデータの費用
Xのデータを読むMakeのシナリオは、データ源への支払いとMakeのクレジットという、2つの請求を払います。Sorsa APIは投稿ごとではなくリクエストごとに課金します。約20投稿の検索ページが1リクエストなので、投稿は1,000件あたり$0.07からで、公式X APIの1,000件あたり$5.00と比べられます。失敗したリクエストに課金されることはありません。
公式X API
$5,000
投稿100万件の場合
1投稿$0.005
Sorsa API
$70から
投稿100万件の場合
1,000件あたり$0.07から
71分の1のコスト
フォロワーと投稿者つきの投稿では、差はさらに広がります。Sorsa APIは1リクエストで200フォロワーを返し、すべての投稿に投稿者のプロフィールが含まれるからです。
| Makeでのデータ | Sorsa API(1,000件あたり) | 公式X API(1,000件あたり) |
|---|---|---|
| 検索、タイムライン、メンション、Listの投稿 | $0.07から | $5.00 |
| 投稿者つきの投稿(2026年11月22日から) | $0.07から | $15.00 |
| フォロワー | $0.007から | $10.00 |
| 100件のバッチで調べるプロフィール | $0.014から | $10.00 |
検索、タイムライン、メンション、Listの投稿
- Sorsa API(1,000件あたり)
- $0.07から
- 公式X API(1,000件あたり)
- $5.00
投稿者つきの投稿(2026年11月22日から)
- Sorsa API(1,000件あたり)
- $0.07から
- 公式X API(1,000件あたり)
- $15.00
フォロワー
- Sorsa API(1,000件あたり)
- $0.007から
- 公式X API(1,000件あたり)
- $10.00
100件のバッチで調べるプロフィール
- Sorsa API(1,000件あたり)
- $0.014から
- 公式X API(1,000件あたり)
- $10.00
Make側はモジュールの実行ごとに課金されます。Makeのクレジットのガイド(新しいタブで開きます)にあるとおり、1オペレーションが1クレジットで、モジュールは処理するバンドルごとに1回実行されます。HTTPモジュールとIteratorは1回の実行につきそれぞれ1クレジット、Iteratorの後ろの各モジュールは、そこに届く投稿ごとに1クレジットで、フィルターとルーターは無料です。MakeのFreeプランには、月1,000クレジットが含まれます。
15分間隔のスケジュールは、30日の月に2,880回実行されます。Sorsa APIのリクエストは2,880回でStarterプランの1万に収まり、最初の投稿が書き込まれる前にMakeのクレジットを5,760消費します。下の計算ツールで、スケジュールに合わせて2つの請求を合算できます。
Sorsa API
2,880
月間リクエスト数
適合するのはStarterプラン (月10K)
無料の100リクエストの持続期間: 約1日
Make
6,960
月間クレジット数
2,880回の実行、投稿の前に1回あたり2クレジット
Freeプランの1,000クレジットを超えます
1回の実行で新規投稿は約0.4件: 約20投稿の1ページで各実行をカバーします。
Makeのクレジットはスケジュールに応じて増えますが、Sorsa APIのリクエストは実行回数とページ数にのみ比例して増えます。
料金は、XのデータソースをMakeにつなぐ前の5つのチェックの1つです。Sorsa APIは、そのすべてを数字で満たしています。
| 確認する項目 | MakeのシナリオでのSorsa API |
|---|---|
| セットアップ | キーチェーンにAPIキー1つ。開発者アプリも、更新が必要なOAuth接続も不要 |
| 速度 | 無料アカウントを含む全プラン毎秒20リクエスト |
| カバー範囲 | 2006年までの検索、タイムライン、メンション、フォロワー、Listを45のエンドポイントで |
| アカウントの安全性 | Xのログイン情報やCookieを求めることはなく、あなたのXアカウントは危険にさらされない |
| 信頼性 | 2022年から本番で稼働。レスポンスのスキーマが安定しているので、フィールドは変わらない |
セットアップ
- MakeのシナリオでのSorsa API
- キーチェーンにAPIキー1つ。開発者アプリも、更新が必要なOAuth接続も不要
速度
- MakeのシナリオでのSorsa API
- 無料アカウントを含む全プラン毎秒20リクエスト
カバー範囲
- MakeのシナリオでのSorsa API
- 2006年までの検索、タイムライン、メンション、フォロワー、Listを45のエンドポイントで
アカウントの安全性
- MakeのシナリオでのSorsa API
- Xのログイン情報やCookieを求めることはなく、あなたのXアカウントは危険にさらされない
信頼性
- MakeのシナリオでのSorsa API
- 2022年から本番で稼働。レスポンスのスキーマが安定しているので、フィールドは変わらない
#Makeで最初のXシナリオを作る
Makeは2025年にXアプリを廃止し、いまはキーヘッダーを持つHTTPモジュール1つで読み取りのすべてをまかないます。そのモジュールをSorsa APIで作ってください。OAuthアプリの代わりに ApiKey のキーチェーン、1リクエストで20投稿または200フォロワー、1,000ツイートあたり$0.07から、そして100回分の無料リクエストで、最初の2,000投稿をまかなえます。
別のツールを使っていますか? n8nでのTwitter APIとZapierでのTwitter APIのガイドで、それぞれのプラットフォームに同じ読み取りを設定できます。
#よくある質問
MakeはいつTwitter(X)連携を削除しましたか?
Makeは2025年4月3日にX(旧Twitter)アプリを削除し、Xモジュールのあるシナリオはそれ以降作成できなくなりました。既存のXシナリオは2025年5月30日まで動き続け、以降は実行のたびに失敗しています。Makeの通知は2026年1月19日が最終更新で、2026年11月2日時点でアプリは復活していないため、シナリオはHTTPアプリ経由でXにアクセスします。
なぜMake.comはX連携をやめたのですか?
Makeは、XのAPIポリシーの要件と料金のために、顧客に妥当な連携を提供できなかったとしています。公式X APIは、すべての読み取りを前払いクレジットで課金します。投稿は1件$0.005、ユーザーは1人$0.010で、膨大な数の小さなシナリオで負担するのは難しい水準です。Grokのモデルを使えるMakeのxAIアプリは、xAIが独自のAPIポリシーを持つため、影響を受けませんでした。
MakeでXのデータを読むのに、Xの開発者アカウントは必要ですか?
不要です。Sorsa APIに必要なのは自分のAPIキーだけで、Makeのキーチェーンに保存して ApiKey ヘッダーで送ります。開発者ポータルも、アプリの審査も、OAuth接続も、前払いのXクレジットもありません。Xの開発者アカウントが必要になるのは、投稿など、シナリオが公式X APIを呼び出す場合だけです。Sorsa APIが返すのは公開データのみで、その利用は、法律とXの規約に対するご自身の責任のもとにあります。
Make.comでは、どのTwitter APIを使えばよいですか?
MakeでXのデータを読むには、Sorsa APIを使ってください。標準のHTTPモジュールで ApiKey のキーチェーン1つで動き、1リクエストで20投稿または200フォロワーを、1,000ツイートあたり$0.07から返します(公式X APIは1,000投稿あたり$5.00)。全プラン毎秒20リクエストで、GETの一覧エンドポイントはMakeの組み込みのカーソルページネーションでページを送れます。
Make.comからXに投稿することはまだできますか?
できます。公式X API経由です。Xの開発者アプリを作り、HTTPモジュールからOAuth 2.0の認証タイプでCreate Postエンドポイントを呼び出します。料金は1投稿$0.015、リンク付きなら$0.200です。Sorsa APIは設計上、読み取り専用で、投稿、いいね、フォローは行わないため、Xアカウントを危険にさらしません。シナリオは、Sorsa APIで読み取りつつ、X側で投稿することも並行してできます。
Makeに、新しいツイートのトリガーはありますか?
ありません。MakeはアプリとともにXの監視モジュールを失い、Sorsa APIにもWebhookはないので、新しい投稿はポーリングで見つけます。シナリオを数分おきにスケジュールし、最新の投稿をリクエストして、created_at のフィルターか、投稿IDをキーとするData storeで、各投稿を1回だけ通します。1回の実行で1リクエストあれば、約20投稿、またはXのList全体のフィードを読み取れます。
#検証の方法
2026年11月2日に、MakeのXアプリに関するリリースノート、HTTPアプリのドキュメント(Make a request、APIキーのキーチェーン、カーソルのページネーションのフィールド)、Makeのクレジット、オペレーション、スケジュールのガイド、そしてMakeのオープンソースのTypeScript SDKにあるブループリントの形式を読みました。同じ日に、docs.x.comでXの料金を確認し、Sorsa APIのすべてのエンドポイント、パラメーター、ページサイズを実際のAPIリファレンスと照合しました。今回はAPIキーがなかったので、リクエスト、レスポンス、ブループリントはそれらのリファレンスに基づいて書いたものです。ブループリントをMakeのアカウントにインポートしてはいません。