### シングルスレッド vs. マルチスレッドリクエスト
各顧客には、検索エンドポイントごとに定められたレート制限があります。Full-Archive search の 1 分あたりのデフォルトレート制限は 120 リクエストであり、平均すると 1 秒あたり 2 クエリ (QPS) です。この平均 QPS は、理論上は毎秒 2 回 API にリクエストできることを意味します。プロダクトのページネーション機能を考えると、1 年分のクエリに関連する投稿が 100 万件あり、それが 1 年間に均等に分布している場合、すべてのデータを取得するには 2,000 件超のリクエストが必要になります (「maxResults」が 500 であると仮定)。1 レスポンスあたり 2 秒かかると仮定すると、1 本のスレッドで直列／逐次的にすべてのデータを取得するには 4,000 秒 (約 1 時間強) かかる計算になります (前のレスポンスの「next」トークンを使って 1 秒あたり 1 リクエスト)。悪くはありません。
次に、データを受信するために 12 本の並列スレッドを使用する状況を考えてみます。100 万件の投稿が 1 年間に均等に分布していると仮定すると、リクエストを 12 本の並列スレッド (マルチスレッド) に分割し、単一の「ジョブ」に対する 1 秒あたりのレート制限をより有効に活用することができます。言い換えると、関心のある各月ごとに 1 本のスレッドを走らせることができ、その結果、データ取得を 12 倍速く (約 6 分) 行える可能性があります。
このマルチスレッドの例は、counts エンドポイントにも同様に当てはまります。例えば、2 年間の期間について投稿数 (Post counts) を取得したい場合、シングルスレッドリクエストを 1 回発行し、31 日単位でページングしながらカウントをさかのぼることができます。1 レスポンスあたり 2 秒かかると仮定すると、24 回の API リクエストを行ってカウントの全セットを取得するのに約 48 秒かかります。しかし、同時に複数の 1 か月単位のリクエストを行うことも可能です。1 秒あたり 12 件のリクエストを行う場合、カウントの全セットはおよそ 2 秒で取得できます。
Twitter Web Client<\/a>",
"truncated": true,
"in_reply_to_status_id": null,
"in_reply_to_status_id_str": null,
"in_reply_to_user_id": null,
"in_reply_to_user_id_str": null,
"in_reply_to_screen_name": null,
"user": {
"id": 175187944,
"id_str": "175187944",
"name": "Tyler Singletary",
"screen_name": "harmophone",
"location": "San Francisco, CA",
"url": "http:\/\/medium.com\/@harmophone",
"description": "@Tagboard の SVP Product。@Klout や @LithiumTech でデータ、ビジネス、プロダクトに携わってきました。@BBI のボードメンバーであり、@Insightpool のアドバイザーでもあります。ホワイトボードの使い方は世界一下手です。",
"translator_type": "null",
"protected": false,
"verified": false,
"followers_count": 1982,
"friends_count": 1877,
"listed_count": 245,
"favourites_count": 23743,
"statuses_count": 12708,
"created_at": "Thu Aug 05 22:59:29 +0000 2010",
"utc_offset": null,
"time_zone": null,
"geo_enabled": false,
"lang": "en",
"contributors_enabled": false,
"is_translator": false,
"profile_background_color": "null",
"profile_background_image_url": "null",
"profile_background_image_url_https": "null",
"profile_background_tile": null,
"profile_link_color": "null",
"profile_sidebar_border_color": "null",
"profile_sidebar_fill_color": "null",
"profile_text_color": "null",
"profile_use_background_image": null,
"profile_image_url": "null",
"profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/719985428632240128\/WYFHcK-m_normal.jpg",
"profile_banner_url": "https:\/\/pbs.twimg.com\/profile_banners\/175187944\/1398653841",
"default_profile": false,
"default_profile_image": false,
"following": null,
"follow_request_sent": null,
"notifications": null
},
"geo": null,
"coordinates": null,
"place": null,
"contributors": null,
"is_quote_status": false,
"extended_tweet": {
"full_text": "\"The innovative crowdsourcing that the Tagboard, Twitter and TEGNA collaboration enables is surfacing locally relevant conversations in real-time and enabling voters to ask questions during debates,” -- @adamostrow, @TEGNA\nLearn More: https:\/\/t.co\/ivAFtanfje",
"display_text_range": [
0,
259
],
"entities": {
"hashtags": [],
"urls": [
{
"url": "https:\/\/t.co\/ivAFtanfje",
"expanded_url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
"display_url": "blog.tagboard.com\/twitter-and-ta…",
"unwound": {
"url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
"status": 200,
"title": "Twitter と Tagboard が連携し、選挙に関する最高のコンテンツを Tagboard を通じてニュースメディアに提供…",
"description": "Tagboard プロダクト責任者 Tyler Singletary による記事"
},
"indices": [
236,
259
]
}
],
"user_mentions": [
{
"screen_name": "adamostrow",
"name": "Adam Ostrow",
"id": 5695942,
"id_str": "5695942",
"indices": [
204,
215
]
},
{
"screen_name": "TEGNA",
"name": "TEGNA",
"id": 34123003,
"id_str": "34123003",
"indices": [
217,
223
]
}
],
"symbols": []
}
},
"quote_count": 0,
"reply_count": 1,
"retweet_count": 6,
"favorite_count": 19,
"entities": {
"hashtags": [],
"urls": [
{
"url": "https:\/\/t.co\/w46U5TRTzQ",
"expanded_url": "https:\/\/twitter.com\/i\/web\/status\/1057384253116289025",
"display_url": "twitter.com\/i\/web\/status\/1…",
"indices": [
117,
140
]
}
],
"user_mentions": [],
"symbols": []
},
"favorited": false,
"retweeted": false,
"possibly_sensitive": false,
"filter_level": "low",
"lang": "en"
},
"is_quote_status": false,
"quote_count": 0,
"reply_count": 0,
"retweet_count": 0,
"favorite_count": 0,
"entities": {
"hashtags": [],
"urls": [],
"user_mentions": [
{
"screen_name": "harmophone",
"name": "Tyler Singletary",
"id": 175187944,
"id_str": "175187944",
"indices": [
3,
14
]
}
],
"symbols": []
},
"favorited": false,
"retweeted": false,
"filter_level": "low",
"lang": "en",
"matching_rules": [
{
"tag": null
}
]
}
],
"requestParameters": {
"maxResults": 100,
"fromDate": "201811010000",
"toDate": "201811060000"
}
}
```
#### カウント用エンドポイントへのアクセス
カウント用エンドポイントを使って、英語の @XDevelopers アカウント発の投稿数を、`day` ごとに集計して取得します。
*cURL は、URL 構文を使用してファイルを取得または送信するためのコマンドラインツールです。*
以下の項目を自身の値に置き換えたうえで、次の cURL リクエストをコマンドラインにコピーしてください。
* **Username** `` 例: `email@domain.com`
* **Account name** `` 例: `john-doe`
* **Label** `` 例: `prod`
* **fromDate と toDate** 例: `"fromDate":"201802010000", "toDate":"201802282359"`
*リクエストを送信すると、パスワードの入力を求められます。*
```bash theme={null}
curl -X POST -u "https://gnip-api.x.com/search/fullarchive/accounts///counts.json" -d '{"query":"from:TwitterDev lang:en","fromDate":"","toDate":"","bucket":"day"}'
```
```bash theme={null}
_これは cURL リクエストの例です。そのまま実行しても動作しません。_
curl -X POST -uemail@domain.com "https://gnip-api.x.com/search/fullarchive/accounts/john-doe/prod/counts.json" -d '{"query":"from:TwitterDev lang:en","fromDate":"201802010000","toDate":"201802282359","bucket":"day"}'
```
#### Counts エンドポイントのレスポンスペイロード
API リクエストに対するレスポンスペイロードは、以下のとおり JSON 形式で返されます。
```json theme={null}
{
"results": [
{
"timePeriod": "201811010000",
"count": 0
},
{
"timePeriod": "201811020000",
"count": 1
},
{
"timePeriod": "201811030000",
"count": 0
},
{
"timePeriod": "201811040000",
"count": 0
},
{
"timePeriod": "201811050000",
"count": 0
}
],
"totalCount": 1,
"requestParameters": {
"bucket": "day",
"fromDate": "201811010000",
"toDate": "201811060000"
}
}
```
お疲れさまでした！これで enterprise Search Posts: Full-Archive API へのアクセスに成功しました。
##### 参考資料
* [ポストオブジェクトの概要](/ja/x-api/enterprise-gnip-2.0/fundamentals/data-dictionary)
* [検索演算子](/ja/x-api/enterprise-gnip-2.0/fundamentals/search-api#enterprise-operators)
* [ポストオブジェクトとペイロード](/ja/x-api/enterprise-gnip-2.0/fundamentals/data-dictionary#post-object)
## ガイド
### 検索クエリの作成
### エンタープライズ向けオペレーター
以下は、X のエンタープライズ検索 API でサポートされているすべてのオペレーターの一覧です。
* **Enterprise** 30 日検索 API
* **Enterprise** フルアーカイブ検索 API
プロダクトごとの利用可能なオペレーターを並べて比較するには、[こちら](/ja/x-api/enterprise-gnip-2.0/fundamentals/rules-filtering#operators-by-product)を参照してください。
| 演算子 | 説明 |
| :--------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| キーワード | ポストの本文または URL 内のトークン化されたキーワードにマッチします。これはトークン化に基づく照合であり、指定したキーワード文字列はポスト本文のトークン化されたテキストと比較されます。トークン化は、句読点、記号、および区切り文字に該当する Unicode 基本多言語面の文字に基づいて行われます。たとえば、テキストが “I like coca-cola” のポストは、次のトークンに分割されます: I, like, coca, cola。これらのトークンが、ルールで使用したキーワード文字列と比較されます。句読点 (例: coca-cola) 、記号、または区切り文字を含む文字列にマッチさせるには、以下で説明する引用符付きの完全一致を使用する必要があります。
**注:** `is:` および `has:` オペレーターは、Search API を使用する場合に単独では使用できず、必ず別の句と組み合わせて使用する必要があります。
たとえば、`@XDeevelopers has:links`
| | |
| :--------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| has:geo | X によって提供された、ポスト固有の位置情報データを持つ投稿にマッチします。これは、「geo」による緯度・経度座標、または対応する表示名、ジオポリゴン、その他のフィールドを含む、X の [“Place”](https://dev.x.com/overview/api/places) 形式の「location」のいずれかです。
### 製品概要
エンタープライズ向けの Full-archive Search は 2015 年 8 月にリリースされ、プレミアム向けバージョンは 2018 年 2 月にリリースされました。これらの検索プロダクトにより、顧客は公開されている任意のポストに即座にアクセスできます。Full-archive Search では、単一のクエリを送信し、従来型の RESTful 方式でレスポンスを受け取ります。Full-archive Search は 1 レスポンスあたり最大 500 件のポストのページネーションを実装しており、レート制限はプレミアム向けが 1 分あたり最大 60 リクエスト (rpm)、エンタープライズ向けが 120 rpm となっています。これらの仕様から、Full-archive Search は同時リクエストを活用することで、大量のポストを高速に取得する用途に適しています。
ディスク上のポストのフラットファイル群を基盤とする Historical PowerTrack とは異なり、Full-archive Search のポストアーカイブはオンラインデータベースに近い構造になっています。すべてのデータベースと同様に、その内容に対してクエリを実行できます。また、高速なデータ取得を可能にするための *index* を利用しています。Full-archive Search エンドポイントでは、クエリ言語は PowerTrack Operators で構成されており、各 Operator はインデックス化されたポストの JSON 属性に対応しています。
また、Historical PowerTrack と同様に、クエリ実行時点の情報を表すポスト属性も存在します。たとえば、Search API を使って 2010 年に投稿されたポストを現在取得すると、そのユーザーのプロフィールの説明文、アカウントの「ホーム」ロケーション、表示名、および「いいね」や Retweet 数といったポストのメトリクスは、2010 年当時ではなく、現在時点の値に更新されて返されます。
### メタデータのタイムライン
以下は、Full-archive search エンドポイントの Operator がマッチし始めた時期のタイムラインです。場合によっては、Operator のマッチングが、X 上で「コミュニケーション上の慣習」が一般的になってからかなり *後* に開始されたものもあります。たとえば、@Replies は 2006 年にユーザーの慣習として現れましたが、それをサポートする JSON を伴った *第一級オブジェクト* や *イベント* になったのは 2007 年初頭でした。そのため、2006 年の @Replies に対してマッチングを行うには、`to:` や `in_reply_to_status_id:` PowerTrack Operator に頼るのではなく、ポスト本文を調査する必要があります。
ここに記載されている詳細は、Full-Archive Search を用いて、数百件におよぶ検索を行った結果に基づいて生成されています。このタイムラインは 100% 完全でも精密でもありません。ユースケースにとって重要となる、他のフィルタリング／メタデータの「誕生日」を見つけた場合は、ぜひお知らせください。
なお、基盤となる Search インデックスは再構築される可能性があります。そのため、これらのタイムラインの詳細は変更される場合があります。
#### 2006
* 3月26日 - `lang:`。検索インデックスを生成する際に、ポストのメタデータがバックフィルされる例。
* 7月13日 - `has:mentions` のマッチングが開始。
* 10月6日 - `has:symbols`。株式銘柄について議論するための $cashtag (または symbol) が一般化するのは2009年初頭になってからであり、それまではほとんどの用法が俗語 (例: $slang) だったと考えられる。
* 10月26日 - `has:links` のマッチングが開始。
* 11月23日 - `has:hashtags` のマッチングが開始。
#### 2007
* 1月30日 - @reply が初めて first-class 扱いとなり (in\_reply\_to\_user\_id) 、`reply_to_status_id:` のマッチングが始まる。
* 8月23日 - トピックや会話を整理する一般的な慣習としてハッシュタグが登場。1週間後に最初の本格的な利用例が現れる。
#### 2009
* 5月15日 - `is:retweet`。このオペレーターは、公式リツイートの「ベータ」版リリースおよびその「Via @」パターンから一致するようになります。このベータ期間中は、ポストの動詞は「post」となり、元のポストはペイロードに含まれません。
* 8月13日 - 公式リツイートの最終版が、「RT @」パターン、動詞「share」、および元のポストを含む `retweet_status` 属性とともにリリースされます (そのため JSON ペイロードサイズはおおよそ2倍になります) 。
#### 2010
* 3月6日 - `has:geo`、`bounding_box:` および `point_radius:` の地理演算子でのマッチングが開始される。
* 8月28日 - `has:videos` (2015年2月まで、この演算子は、youtube.com や vimeo.com、vivo.com など一部の動画ホスティングサイトへのリンクを含む投稿にマッチします) 。
#### 2011
* 7月20日 - `has:media` と `has:images` が検索でマッチするように。ネイティブ写真機能は2010年8月9日に正式発表。
#### 2014
* 12月3日ごろ - *一部の* [Enhanced URL metadata](/ja/x-api/enterprise-gnip-2.0/fundamentals/data-enrichments) が HTML の title と description とともにペイロードに含まれるようになりました。拡張メタデータは 2016年5月に、より完全な形で導入されました。
#### 2015
* 2月10日 - `has:videos` は「ネイティブ」な X 動画にマッチします。
* 2月17日 - `has:profile_geo`, `profile_country:`, `profile_region:`, `profile_locality:` [Profile Geo](/ja/x-api/enterprise-gnip-2.0/fundamentals/data-enrichments#profile-geo) オペレーターがマッチングに対応し始めます。
* 2月17日 - `place_country:` と `place:` ポストのジオオペレーターがマッチングに対応し始めます。
#### 2016
* 5月1日 - [Enhanced URL metadata](/ja/x-api/enterprise-gnip-2.0/fundamentals/data-enrichments) が本格的に利用可能となり、[2016年8月の Gnip 2.0 ローンチ](https://blog.x.com/2016/gnip-2-is-here) の一部として正式に発表されました。Search API には、これらのメタデータに対応する Operator は用意されていません。
#### 2017
* 2月22日 - 投票メタデータが拡張されたネイティブ形式で利用可能になりました。これらのメタデータに対応する Operator はありません。
#### 2022
* 9月27日 - この日以降に作成されたすべてのポストオブジェクトには、編集ポストのメタデータが利用可能です。ポストオブジェクトを提供するすべての Enterprise エンドポイントは、この日からこのメタデータを提供するように更新されました。提供される編集メタデータには、`edit_history` および `edit_controls` オブジェクトが含まれます。これらのメタデータは、2022年9月27日以前に作成された投稿については返されません。現時点では、これらのメタデータに対応する Enterprise Operator はありません。編集ポストのメタデータについて詳しくは、[Edit Posts fundamentals](/ja/x-api/fundamentals/edit-posts) ページを参照してください。
#### 2022
* 9月29日 - この日以降に作成されたすべてのポストオブジェクトでは、編集済みポストのメタデータが利用可能です。ポストオブジェクトを提供するすべての Enterprise エンドポイントは、この日からこのメタデータを提供するように更新されました。提供される編集メタデータには、edit\_history オブジェクトと edit\_controls オブジェクトが含まれます。これらのメタデータは、2022年9月27日より前に作成された投稿については返されません。現在のところ、これらのメタデータに対応する Enterprise Operators は存在しません。ポスト編集メタデータの詳細については、[ポスト編集の基本](/ja/x-api/fundamentals/edit-posts) ページを参照してください。
### フィルタリングのヒント
ここまで説明してきたタイムライン情報から分かるように、Search API のフィルターを作成する際には多くの詳細を考慮する必要があります。特に重要な点が 2 つあります。
* 一部のメタデータには「付与開始日」があるため、フィルターの結果に *偽陰性* が含まれる可能性があります。これは、検索期間全体または一部では存在していなかったメタデータに依存するオペレーターを使った検索です。たとえば、`has:images` オペレーターを使ってポストを検索する場合、2011 年 7 月より前の期間についてはヒットが一切ありません。これは、そのオペレーターが (X のユーザーインターフェースを使ってポストに添付された) *ネイティブ* 写真にマッチするためです。写真共有ポストのより完全なデータセットを取得するには、2011 年 7 月より前の期間に対するフィルターでは、写真ホスティング用の一般的な URL にマッチするルール句を含める必要があります。
* 一部のメタデータは、ポストが X に投稿された時点より *後* の時点のメタデータでバックフィルされています。
PowerTrack クエリを作成する際に、一般的に注目される属性タイプがいくつかあります。
* X Profiles
* オリジナルポストまたは共有ポスト
* ポストの言語分類
* 位置情報参照付きポスト
* 共有リンクのメディア
これらの中にはプロダクト固有の動作をするものもあれば、同一の動作をするものもあります。詳細は以下を参照してください。
#### X プロフィール
Search APIs は、*取得時点* のユーザープロフィールデータが付与された過去の投稿を返します。たとえば 2014 年の投稿をリクエストした場合でも、そのユーザーのプロフィールメタデータは、クエリを実行した時点での状態を反映します。
#### 元の投稿とリツイート
PowerTrack の `_is:retweet_` オペレーターを使うと、リツイートを含めるか除外するかを指定できます。このオペレーターを利用する場合、2009 年 8 月以前のデータについては、リツイートとしてマッチさせるか (あるいはマッチさせないか) のために 2 つの戦略を用意しておく必要があります。2009 年 8 月以前は、「@RT 」パターンに一致するかどうかを確認するために、ポスト本文自体を正確なフレーズ一致でチェックする必要があります (実際には、2009 年 5〜8 月のリツイートをフィルタリングする場合は、「Via @」パターンも含める必要があります) 。2009 年 8 月以降の期間については、*is:retweet* オペレーターが利用可能です。
#### ポストの言語分類
ポストの言語分類でフィルタリングする場合、X の過去のプロダクト間では挙動が大きく異なります。Search アーカイブが構築されたとき、すべての投稿に対して X の言語分類がさかのぼって付与されました。そのため、`lang:` オペレーターはすべてのポストのアーカイブ全体に対して利用できます。
#### ポストの地理参照
投稿を地理参照する主な方法は 3 つあります。
* **投稿本文内の地理的な記述。** 投稿本文内の地理的な記述に基づいてマッチングする方法は、ローカルな知識に依存するため最も難しい方法であることが多いものの、全投稿アーカイブに対して利用できるオプションです。[こちら](https://x.com/biz/statuses/28311)は、「golden gate」フィルターに基づいてサンフランシスコ地域を対象に 2006 年に行われた地理参照マッチの例です。
* **ユーザーがジオタグ付けした投稿。** Search APIs では、2010 年 3 月から一部の Geo オペレーターを使って投稿のマッチングができるようになり、2015 年 2 月からは他の Geo オペレーターも利用可能になりました。
* 2010 年 3 月 6 日: `has:geo`、`bounding_box:`、`point_radius:`
* 2015 年 2 月 17 日: `place_country:`、`place:`
* **ユーザーがアカウントプロフィールの「ホーム」位置情報を設定。** Profile Geo オペレーターは Historical PowerTrack と Search APIs の両方で利用できます。Search APIs では、これらの Profile Geo メタデータは 2015 年 2 月から利用可能です。Profile Geo メタデータが利用可能になる前に投稿されたコンテンツについては、正規化されていないユーザー入力にマッチさせるために使用できる `bio_location:` オペレーターが用意されています。
#### 共有リンクとメディア
2012年3月に、拡張 URL エンリッチメントが導入されました。この時期以前は、ポストのペイロードにはユーザーが指定した URL のみが含まれていました。そのため、ユーザーが短縮 URL を含めていた場合、関心のある (展開済み) URL と照合するのが難しいことがありました。Search API では、これらのメタデータは 2012 年 3 月以降利用可能です。
2016年7月には、強化 URL エンリッチメントが導入されました。この強化版では、ポストのペイロードに Web サイトの HTML のタイトルと説明が含まれ、それらに対してマッチングするためのオペレーターも提供されます。これらのメタデータは 2014 年 12 月頃から現れ始めています。
2016年9月、X は「ネイティブアタッチメント」を導入し、末尾の共有リンクがポストの 140 文字制限にはカウントされなくなりました。両方の URL エンリッチメントは、これらの共有リンクにも引き続き適用されます。
関連する Search オペレーターがマッチし始める時期は次のとおりです。
* 2006年10月26日 - `has:links`
* 2011年7月20日 - `has:images` と `has:media`
* 2011年8月 - `url:` ([Expanded URLs エンリッチメント](/ja/x-api/enterprise-gnip-2.0/fundamentals/data-enrichments) を利用) 。早い例では 2006 年 9 月の `(url:"spotify.com" OR url:gnip OR url:microsoft OR url:google OR url:youtube)` が [http://x.com/Adam/statuses/16602](http://x.com/Adam/statuses/16602) にマッチします。twitter\_entities や gnip オブジェクトには urls\[] メタデータが存在しないにもかかわらずです。`"youtube.com"` は、urls\[] メタデータが一切なくても `url:youtube` にマッチするメッセージコンテンツの一例です。
* 2015年2月10日 - ネイティブ動画に対する `has:videos`。2010/08/28 から 2015/02/10 の間、このオペレーターは youtube.com、vimeo.com、vivo.com などの特定の動画ホスティングサイトへのリンクを含むポストにマッチします。
* 2016年5月1日 - [Enhanced URLs エンリッチメント](/ja/x-api/enterprise-gnip-2.0/fundamentals/data-enrichments) に基づく `url_title:` と `url_description:` が一般提供開始。最初の強化 URL メタデータは 2014 年 12 月に現れ始めました。
## よくある質問 (FAQ)
### Search Post API 全般に関する質問
counts エンドポイントと data エンドポイントによって提供される結果には、差異が生じることが知られています。counts エンドポイントはコンプライアンス適用前 (削除された投稿や位置情報のスクラブなどを考慮しない状態) である一方、data エンドポイントは配信時点でコンプライアンスに準拠し、すべてのコンプライアンスイベントを反映しているため、結果に不一致が生じる場合があります。
これが起こりうる理由はいくつかあり、たとえば次のとおりです。
1. 期待していたポストが非公開アカウントのものである場合
2. データエンドポイントではすべてのコンプライアンスイベントが考慮されるため (削除された投稿やジオ情報が削除されたものなどは、レスポンスに含まれません) 。
これは、Premium のルールおよびフィルタリング機能の誤った利用が原因である可能性が高いです。[こちらのドキュメント](/ja/x-api/enterprise-gnip-2.0/fundamentals/rules-filtering)を確認し、ルールを作成する際の制約事項を十分に理解してください。
はい、あります。例えば次のようなものです。
* [Tweepy](http://www.tweepy.org/) - 標準的な search/投稿 プロダクトを利用するのに適しています (Python)
* [X API](https://github.com/geduldig/TwitterAPI) - 標準的な Search Post API を利用するのに適しています (Python)
* [Search Posts Python](https://github.com/xdevplatform/search-tweets-python) と [Search Posts Ruby](https://github.com/xdevplatform/search-tweets-ruby) - enterprise (および v2！) の Search Post API で使用できる、便利な 2 つのツールです
X が直接サポートしているライブラリはすべて、xdevplatform の GitHub ページに掲載されています: [https://github.com/xdevplatform](https://github.com/xdevplatform)。
[他のサードパーティ製ライブラリ](/ja/resources/fundamentals/authentication#oauth-1-0a-2)もあり、役立つ場合があります。ただし、これらの一部は Premium および Enterprise 製品では動作しない場合がある点に注意してください。
はい。データエンドポイントは、指定された `maxResults` に達するか、30 日が経過した時点のいずれか早い方でページネーションされます。
たとえば、ある 30 日間に 800 件の投稿がある場合、すべての結果を取得するには 2 回リクエストを行う必要があります。1 回のリクエストで返せる投稿の最大数は 500 件 (`maxResults`) だからです。また、1 か月目に 400 件、2 か月目に 100 件の投稿がある場合も、完全な結果を取得するには 2 回のリクエストが必要です。最初のリクエストで指定した `maxResults` 未満の投稿しか返されなかった場合でも、30 日が経過するとページネーションが行われるためです。
投稿は新しいものから古いものへと、逆時系列で返されます。たとえば、最初のページにはクエリに一致する最新の投稿が表示され、結果の投稿日時が最初にリクエストした `fromDate` に到達するまでページネーションが続きます。
課金対象となるのは元のポストだけです。以降の編集は無視され、アクティビティ全体のカウントには加算されません。
`Enterprise`
当社のエンタープライズ向けソリューションは、お客様のビジネスニーズに合わせて、料金を見通しやすい形でカスタマイズされています。詳しくは、[こちら](/ja/x-api/enterprise-gnip-2.0/enterprise-gnip) からお申し込みください。
* エンタープライズ向け Search ポスト API のドキュメントは[こちら](/ja/x-api/enterprise-gnip-2.0/fundamentals/search-api#enterprise-search-apis)をご覧ください
* ルールとフィルタリングに関する有用な情報は[こちら](/ja/x-api/enterprise-gnip-2.0/fundamentals/rules-filtering#enterprise-operators)をご覧ください
* data エンドポイントの利用に関する有用な情報は[こちら](/ja/x-api/enterprise-gnip-2.0/fundamentals/search-api#data-endpoint)をご覧ください
* counts エンドポイントの利用に関する有用な情報は[こちら](/ja/x-api/enterprise-gnip-2.0/fundamentals/search-api#counts-endpoint)をご覧ください
* 利用可能なオペレーターの一覧は[こちら](/ja/x-api/enterprise-gnip-2.0/fundamentals/search-api#available-operators)をご覧ください
この件については、Xの担当アカウントマネージャーまでお問い合わせください。
### エラー対処ガイド
**コード 404 - Not Found**
1. 各エンドポイントに対して適切なパラメータを使用していることを確認してください (例：`buckets` フィールドは counts エンドポイントでのみ使用でき、data エンドポイントでは使用できません)
2. `:product`、`:account_name`、`:label` フィールドが正しいことを再度確認してください。`:label` フィールドは GNIP コンソール (エンタープライズ顧客のみ) で確認できます。
## APIリファレンス
### Enterprise search APIs
エンタープライズ検索 API には 2 種類あります。
* 30-Day Search API - 過去 30 日間に投稿されたツイートを提供します。
* Full-Archive Search API - 2006 年 3 月に投稿された最初のツイート以降のツイートを提供します。
これらの検索 API は共通の設計となっており、以下の説明は両方に適用されます。2022 年 9 月 29 日以降に作成されたツイートについては、その編集履歴を表すツイート編集メタデータが Tweet オブジェクトに含まれる点に注意してください。詳細については、「[Edit Tweets](/ja/x-api/enterprise-gnip-2.0/fundamentals/edit-tweets)」の基礎ページを参照してください。
以下は、エンタープライズ検索 API と統合する際に必要となる重要なポイントです。
* ツイートデータおよび件数をリクエストするメソッド
* 認証
* ページネーション
* API リクエストパラメータとリクエスト例
* API レスポンスの JSON ペイロードとレスポンス例
* HTTP レスポンスコード
エンタープライズ API は、低レイテンシーかつ完全な精度で、クエリベースによるツイートアーカイブへのアクセスを提供します。2 つの API の違いは検索できる期間だけで、直近 30 日間か、2006 年までさかのぼれるかの違いです。期間は分単位の粒度で指定できます。ツイートデータは、クエリにマッチする最新のツイートから始まる逆時系列で提供されます。ツイートは、公開されてからおおよそ 30 秒後に検索 API から利用可能になります。
#### メソッド
エンタープライズ検索のベースとなる URI は `https://gnip-api.x.com/search/` です。
| Method | Description |
| :---------------------------------------------------------------------------- | :--------------------------------------------- |
| [POST /search/:product/accounts/:account\_name/:label](#SearchRequests) | 指定した PowerTrack ルールに一致する、過去 30 日間のツイートを取得します。 |
| [POST /search/:product/accounts/:account\_name/:label/counts](#CountRequests) | 指定した PowerTrack ルールに一致する、過去 30 日間のツイート数を取得します。 |
ここで:
* `:product` はリクエストを送信する検索エンドポイントを表し、`30day` または `fullarchive` のいずれかです。
* `:account_name` は、console.gnip.com に表示されるアカウントに関連付けられた (大文字・小文字を区別する) 名前です。
* `:label` は、console.gnip.com に表示される検索エンドポイントに関連付けられた (大文字・小文字を区別する) ラベルです。
たとえば、TwitterDev アカウントがラベル「prod」 (production の略) を持つ 30 日検索プロダクトを利用している場合、検索エンドポイントは次のようになります。
* データエンドポイント: [https://gnip-api.x.com/search/30day/accounts/TwitterDev/prod.json](https://gnip-api.x.com/search/30day/accounts/TwitterDev/prod.json)
* カウントエンドポイント: [https://gnip-api.x.com/search/30day/accounts/TwitterDev/prod/counts.json](https://gnip-api.x.com/search/30day/accounts/TwitterDev/prod/counts.json)
ご利用中のエンタープライズ検索 API の完全なエンドポイントは [https://console.gnip.com](https://console.gnip.com) に表示されます。
以下に、curl というシンプルな HTTP ユーティリティを使った、いくつかのリクエスト例を示します。これらの例では、URL に `:product`、`:account_name`、`:label` を使用しています。これらの例を利用する際は、ご自身の情報に合わせて URL を更新してください。
#### 認証
Enterprise search API へのすべてのリクエストは、[https://console.gnip.com](https://console.gnip.com) のアカウントへのログインに使用する有効なメールアドレスとパスワードの組み合わせから構成される HTTP の *Basic Authentication* を使用する必要があります。認証情報は、各リクエストで *Authorization* ヘッダーとして送信する必要があります。
#### リクエスト／レスポンスの挙動
`fromDate` と `toDate` パラメータを使用することで、API がサポートする任意の期間をリクエストできます。30-Day search API は直近 31 日分のツイートを提供します (「30-Day」API と呼ばれていますが、ユーザーが完全な 1 か月分をリクエストできるように 31 日分を利用可能にしています) 。Full-Archive search API は、最初のツイート (2006 年 3 月 21 日) までさかのぼってツイートを提供します。ただし、単一のレスポンスに含まれるのは、指定した `maxResults` または 31 日分のうち小さい方までです。一致するデータ量または指定した時間範囲が、指定した `maxResults` または 31 日を超える場合、指定した期間の残りの部分をページングするために使用すべき `next` トークンが返されます。
たとえば、Full-Archive search を使用して、2017 年 1 月 1 日から 2017 年 6 月 30 日までの間でクエリに一致するすべてのツイートを取得したいとします。リクエストでは、`fromDate` と `toDate` パラメータを使用して、その 6 か月間全体を指定します。search API は、最初の「ページ」のツイートを返し、そのツイート数は `maxResults` パラメータ (デフォルトは 100) で指定した数になります。さらにツイートが存在する場合 (通常は存在します) 、API は次のデータ「ページ」をリクエストできるようにする `next` トークンも返します。この処理は、API が `next` トークンを返さなくなるまで繰り返されます。詳細については次のセクションを参照してください。
データリクエストとカウントリクエストの両方を行う場合、単一のレスポンスで返せる量を超えてデータが存在することがあります。そのような場合、レスポンスには「next」トークンが含まれます。「next」トークンは、ルートレベルのJSON属性として提供されます。「next」トークンが提供されている場合は常に、取得可能な追加データが存在することを意味するため、APIリクエストを継続して実行する必要があります。
**Note:** 「next」トークンの挙動は、データリクエストとカウントリクエストでわずかに異なります。両方の動作については、APIリファレンスセクションでのレスポンス例とともに説明しています。
データをリクエストする場合、1 回のレスポンスで返せる量を超えるデータが生成される可能性があります。各データリクエストには、1 回のリクエストで返すツイートの最大数を設定するパラメータが含まれています。この `maxResults` パラメータのデフォルト値は 100 で、10～500 の範囲で設定できます。クエリに一致するツイートの数が、リクエストで使用した `maxResults` パラメータを超える場合、レスポンスには 'next' トークン (ルートレベルの JSON 属性) が含まれます。この 'next' トークンは後続のリクエストで使用し、そのクエリに一致するツイートの次の部分 (すなわち次の「ページ」) を取得するためのものです。'next' トークンは、そのクエリの結果の最後の「ページ」に到達し、'next' トークンが返されなくなるまで提供され続けます。
次の「ページ」のデータをリクエストするには、元のクエリとまったく同じクエリを実行する必要があります。必要に応じて `query`、`toDate`、`fromDate` パラメータを含め、さらに前回のレスポンスで返された値を設定した 'next' リクエストパラメータも含めます。これは GET リクエストと POST リクエストのいずれでも利用できます。ただし、GET リクエストの場合、'next' パラメータは URL エンコードされている必要があります。
クエリの対象期間をカバーするすべてのツイートを受信するまで、前回のクエリで受け取った 'next' トークンを引き続き渡すことができます。'next' トークンを含まないレスポンスを受信した場合、それは最後のページに到達しており、指定したクエリおよび期間に対して利用できる追加データがないことを意味します。
`counts` エンドポイントは、クエリに関連付けられたツイート数を、日次、時間単位、または分単位のいずれかの粒度で提供します。`counts` API エンドポイントは、最大 31 日分のカウントをタイムスタンプ付き配列として返します。31 日を超える期間のカウントをリクエストした場合、`next` トークンが返されます。データ用の `next` トークンと同様に、元とまったく同じクエリを送信し、前回のレスポンスで返された値を設定した `next` リクエストパラメータも含める必要があります。
31 日を超えるカウントをリクエストする場合以外にも、`next` トークンが提供されるシナリオがあります。ボリュームの大きいクエリでは、カウントの生成に時間がかかり、レスポンスのタイムアウトが発生する可能性があります。この場合、31 日分より少ないカウントしか受け取れませんが、カウントのペイロード全体を取得し終えるまでリクエストを継続できるように、`next` トークンが返されます。***重要:*** タイムアウトが発生した場合、レスポンスには完全な「バケット」のみが含まれます。そのため、2.5 日分のデータがある場合は、2 日分の完全な「バケット」のみが結果として返されます。
##### 追加の注意事項
* 検索リクエストで fromDate または toDate を使用する場合、取得できる結果は指定した時間範囲内のものだけになります。時間範囲内の結果の最後のグループに到達すると、`next` トークンは返されません。
* `next` 要素は、maxResults の値が 10〜500 の任意の値 (デフォルト値は 100) で使用できます。maxResults は各レスポンスで返されるツイート数を決定しますが、最終的にすべての結果を取得することを妨げるものではありません。
* `next` 要素には有効期限がありません。同じ `next` クエリを使用した複数のリクエストは、リクエストのタイミングに関係なく同じ結果を受け取ります。
* `next` パラメータを使用して結果をページングする場合、クエリの境界付近で重複が発生することがあります。アプリケーション側でこれらの重複を許容できるようにしておく必要があります。
#### データエンドポイント
##### POST /search/:product/:label
###### エンドポイントパターン:
このエンドポイントは、指定されたクエリおよび期間に対応するデータを返します。期間が指定されていない場合、時間パラメータはデフォルトで直近30日間になります。注記: 以下で説明するパラメータを URL にエンコードすることで、POST ではなく GET リクエストを使用して同じ機能を実行することもできます。
##### データリクエストパラメータ
| Parameters | Description | Required | Sample Value |
| :--------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------- | :--------------------------------- |
| query | 最大 2,048 文字まで指定できる、1 つの PowerTrack ルールと同等の内容を指定します (肯定および否定の句の数に制限はありません) 。
###### 追加の詳細
| | |
| :----------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **利用可能な期間** | 30-Day: 直近31日間
##### データリクエストとレスポンスの例
###### POST リクエストの例
* POST リクエストのパラメータは、以下のように JSON 形式のボディで送信されます。
* 取得対象の PowerTrack ルールのすべての部分 (例: キーワード、bounding\_box: のようなその他のオペレーター) は、'query' パラメータに含める必要があります。
* ルールの一部をクエリ URL 内の別々のパラメータとして分割しないでください。
以下は、初回データリクエストを行うための、cURL を使用した POST コマンドの例です。
```bash theme={null}
curl -X POST -u "https://gnip-api.x.com/search/:product/accounts/:account_name/:label.json" -d '{"query":"from:twitterDev","maxResults":500,"fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm"}'
```
API データレスポンスに 'next' トークンが含まれている場合、以下は、元のリクエストの 'next' パラメータに指定されたトークンを設定した後続リクエストの例です。
```bash theme={null}
curl -X POST -u "https://gnip-api.x.com/search/:product/accounts/:account_name/:label.json" -d '{"query":"from:twitterDev","maxResults":500,"fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm",
"next":"NTcxODIyMDMyODMwMjU1MTA0"}'
```
###### GET リクエストの例
* GET リクエストのパラメータは、標準的な URL エンコードを用いて URL にエンコードされます。
* クエリ対象となる PowerTrack ルールのすべての要素 (例: キーワード、`bounding_box:` のような他のオペレーター) は、`query` パラメータに含める必要があります。
* クエリ URL 内で、ルールの一部を個別のパラメータとして分割しないでください。
以下は、初回のデータリクエストを行うための、cURL を使用した GET コマンドの例です。
```bash theme={null}
curl -u "http://gnip-api.x.com/search/:product/accounts/:account_name/:label.json?query=from%3Atwitterdev&maxResults=500&fromDate=yyyymmddhhmm&toDate=yyyymmddhhmm"
```
###### データレスポンスの例
2022年9月29日以降に作成されたツイートの場合、Tweet オブジェクトには、その編集履歴を表すツイート編集メタデータが含まれます。詳細については、["ツイートの編集"](/ja/x-api/enterprise-gnip-2.0/fundamentals/edit-tweets) の基本事項のページを参照してください。
以下はデータクエリに対するレスポンスの例です。この例では、利用可能なツイートが 'maxResults' を超えていることを前提としているため、後続のリクエスト用に 'next' トークンが返されています。クエリに関連付けられたツイートが 'maxResults' 以下の場合、レスポンスには 'next' トークンは含まれません。
'next' 要素の値はクエリごとに変化し、不透明な文字列として扱う必要があります。レスポンスボディ内での 'next' 要素は次のような形式になります。
```json theme={null}
{
"results":
[
{--Tweet 1--},
{--Tweet 2--},
...
{--Tweet 500--}
],
"next":"NTcxODIyMDMyODMwMjU1MTA0",
"requestParameters":
{
"maxResults":500,
"fromDate":"201101010000",
"toDate":"201201010000"
}
}
```
後続のリクエストに対するレスポンスは、次のようになります (新しいツイートや異なる 'next' の値に注目してください) :
```json theme={null}
{
"results":
[
{--Tweet 501--},
{--Tweet 502--},
...
{--Tweet 1000--}
],
"next":"R2hCDbpBFR6eLXGwiRF1cQ",
"requestParameters":
{
"maxResults":500,
"fromDate":"201101010000",
"toDate":"201201010000"
}
}
```
直前のクエリで返された 'next' 要素を引き続き指定し続けることで、そのクエリで指定した期間に含まれるすべてのツイートを取得できます。'next' 要素を含まないレスポンスを受け取った場合は、最後のページに到達しており、指定した時間範囲内で取得可能な追加データがないことを意味します。
#### カウント用エンドポイント
##### /search/:stream/counts
###### エンドポイントパターン:
`/search/fullarchive/accounts/:account_name/:label/counts.json`
このエンドポイントは、指定されたクエリに対するカウント (データボリューム) データを返します。期間が指定されていない場合、時間パラメーターのデフォルトは直近30日間になります。データボリュームは、日単位、時間単位 (デフォルト) 、または分単位のいずれかで、タイムスタンプ付き配列として返されます。
**注:** この機能は、以下で説明するパラメーターを URL にエンコードすることで、POST ではなく GET リクエストを使用して実行することもできます。
##### カウントリクエストのパラメータ
| Parameters | Description | Required | Sample Value |
| :--------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------- | :--------------------------------- |
| query | 1 つの PowerTrack ルールに相当するクエリで、最大 2,048 文字まで指定できます (肯定/否定の句の数に制限はありません) 。
###### 追加の詳細
| | |
| :---------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **利用可能な期間** | 30-Day: 直近31日間
##### カウント用リクエストとレスポンスの例
###### POST リクエストの例
* POST リクエストのパラメータは、以下のように JSON 形式のボディで送信されます。
* クエリ対象とする PowerTrack ルールのすべての要素 (例: キーワード、bounding\_box: のようなその他のオペレーター) は、'query' パラメータに含めて指定してください。
* ルールの一部を、クエリ URL の別個のパラメータとして分割しないでください。
以下は、初回の counts リクエストを行うための POST (cURL 使用) コマンドの例です。
```bash theme={null}
curl -X POST -u "https://gnip-api.x.com/search/:product/accounts/:account_name/:label/counts.json" -d '{"query":"TwitterDev","fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm","bucket":"day"}'
```
API の counts レスポンスに 'next' トークンが含まれている場合、以下に示すのは、提供されたトークンを 'next' パラメーターに設定した、元のリクエストと同一内容の後続リクエストです。
```bash theme={null}
curl -X POST -u "https://gnip-api.x.com/search/:product/accounts/:account_name/:label/counts.json" -d '{"query":"TwitterDev","fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm","bucket":"day",
"next":"YUcxO87yMDMyODMwMjU1MTA0"}'
```
###### GET リクエストの例
* GET リクエストのリクエストパラメータは、標準的な URL エンコード方式で URL にエンコードされます
* クエリ対象の PowerTrack ルールのすべての要素 (例: キーワード、bounding\_box: のようなその他のオペレーター) は、'query' パラメータに指定してください
* ルールの要素を分割して、query URL 内の別々のパラメータとして指定しないでください
以下は、初回の counts リクエストを送信するための GET (cURL 使用) コマンドの例です：
```bash theme={null}
curl -u "http://gnip-api.x.com/search/fullarchive/accounts/:account_name/:label/counts.json?query=TwitterDev&bucket=day&fromDate=yyyymmddhhmm&toDate=yyyymmddhhmm"
```
#### カウントレスポンスの例
以下は、counts (データボリューム) クエリに対するレスポンスの例です。このレスポンス例には 'next' トークンが含まれており、これは counts リクエストの対象期間が 31 日を超えているか、もしくは送信されたクエリに関連付けられたデータ量が十分に大きく、部分的なレスポンスが返される条件を満たしたことを意味します。
'next' 要素の値はクエリごとに変化し、不透明な文字列として扱う必要があります。レスポンスボディ内での 'next' 要素は、次のような形式になります。
```json theme={null}
{
"results": [
{ "timePeriod": "201101010000", "count": 32 },
{ "timePeriod": "201101020000", "count": 45 },
{ "timePeriod": "201101030000", "count": 57 },
{ "timePeriod": "201101040000", "count": 123 },
{ "timePeriod": "201101050000", "count": 134 },
{ "timePeriod": "201101060000", "count": 120 },
{ "timePeriod": "201101070000", "count": 43 },
{ "timePeriod": "201101080000", "count": 65 },
{ "timePeriod": "201101090000", "count": 85 },
{ "timePeriod": "201101100000", "count": 32 },
{ "timePeriod": "201101110000", "count": 23 },
{ "timePeriod": "201101120000", "count": 85 },
{ "timePeriod": "201101130000", "count": 32 },
{ "timePeriod": "201101140000", "count": 95 },
{ "timePeriod": "201101150000", "count": 109 },
{ "timePeriod": "201101160000", "count": 34 },
{ "timePeriod": "201101170000", "count": 74 },
{ "timePeriod": "201101180000", "count": 24 },
{ "timePeriod": "201101190000", "count": 90 },
{ "timePeriod": "201101200000", "count": 85 },
{ "timePeriod": "201101210000", "count": 93 },
{ "timePeriod": "201101220000", "count": 48 },
{ "timePeriod": "201101230000", "count": 37 },
{ "timePeriod": "201101240000", "count": 54 },
{ "timePeriod": "201101250000", "count": 52 },
{ "timePeriod": "201101260000", "count": 84 },
{ "timePeriod": "201101270000", "count": 120 },
{ "timePeriod": "201101280000", "count": 34 },
{ "timePeriod": "201101290000", "count": 83 },
{ "timePeriod": "201101300000", "count": 23 },
{ "timePeriod": "201101310000", "count": 12 }
],
"totalCount":2027,
"next":"NTcxODIyMDMyODMwMjU1MTA0",
"requestParameters":
{
"bucket":"day",
"fromDate":"201101010000",
"toDate":"201201010000"
}
}
```
後続のリクエストに対するレスポンスは、次のようになります (新しい counts タイムラインと異なる「next」値に注目してください) ：
```json theme={null}
{
"results": [
{ "timePeriod": "201102010000", "count": 45 },
{ "timePeriod": "201102020000", "count": 76 },
....
{ "timePeriod": "201103030000", "count": 13 }
],
"totalCount":3288,
"next":"WE79fnakFanyMDMyODMwMjU1MTA0",
"requestParameters":
{
"bucket":"day",
"fromDate":"201101010000",
"toDate":"201201010000"
}
}
```
前回のクエリから返された 'next' 要素を引き続き渡すことで、そのクエリの時間範囲内に含まれるすべてのカウントを取得するまでページングを続けることができます。'next' 要素を含まないレスポンスを受け取った場合、それは最後のページに到達しており、指定した時間範囲内で取得可能な追加のカウントが存在しないことを意味します。
#### HTTP response codes
| Status | Text | Description |
| :----- | :-------------------- | :-------------------------------------------------------------------------------------- |
| 200 | OK | リクエストは成功しました。JSON レスポンスは次の例と同様の形式になります。 |
| 400 | Bad Request | 通常、このレスポンスは、リクエスト内に無効な JSON が含まれている場合、または JSON ペイロードがまったく送信されなかった場合に返されます。 |
| 401 | Unauthorized | 無効な認証情報により HTTP 認証に失敗しました。お使いの認証情報で console.gnip.com にログインし、リクエストで正しく使用していることを確認してください。 |
| 404 | Not Found | リクエストが送信された URL にリソースが存在しません。誤った URL が使用されている可能性があります。 |
| 422 | Unprocessable Entity | クエリ内のパラメータが無効な場合に返されます (例: 無効な PowerTrack ルール) 。 |
| 429 | Unknown Code | アプリケーションが接続リクエスト数の上限を超過しました。対応する JSON メッセージは次の例と同様の形式になります。 |
| 500 | Internal Server Error | サーバー側でエラーが発生しました。指数バックオフ方式を用いてリクエストを再試行してください。 |
| 502 | Proxy Error | サーバー側でエラーが発生しました。指数バックオフ方式を用いてリクエストを再試行してください。 |
| 503 | Service Unavailable | サーバー側でエラーが発生しました。指数バックオフ方式を用いてリクエストを再試行してください。 |