レート制限

レート制限とは、一定期間内にアプリやユーザーが実行できるAPI呼び出しの数です。この制限を超えるか、CPU時間または合計時間の制限を超えると、アプリやユーザーがスロットリングされることがあります。スロットリングされたユーザーやアプリの発行するAPIリクエストは失敗します。

すべてのAPIリクエストはレート制限に従います。グラフAPIとInstagram基本表示APIのリクエストはプラットフォームレート制限に従い、マーケティングAPIとInstagramプラットフォームのリクエストはビジネスユースケース(BUC)レート制限に従います。

ページAPIリクエストは、リクエストで使用されるトークンに応じて、プラットフォームレート制限またはBUCレート制限に従います。アプリアクセストークンまたはユーザーアクセストークンを使用したリクエストは、プラットフォームレート制限に従います。システムユーザートークンまたはページアクセストークンを使用したリクエストは、ビジネスユースケースレート制限に従います。

エンドポイントに対して相当数の呼び出しが行われると、ほとんどのAPI応答に含まれるヘッダーに、リアルタイムのレート制限使用統計が書き込まれます。プラットフォームレート制限の使用統計は、アプリダッシュボードにも表示されます。呼び出しがレート制限に達すると、それ以降アプリが発行するリクエストはすべて失敗し、呼び出しカウントが制限を下回るのに十分な時間が経過するまで、APIはエラーコードを返します。

プラットフォームレート制限とビジネスユースケースレート制限の両方がリクエストに適用可能な場合は、BUCレート制限が適用されます。

プラットフォームレート制限

プラットフォームレート制限は、リクエストで使用されるトークンのタイプに応じて、個々のアプリまたはユーザーレベルでトラッキングされます。

アプリ

アプリアクセストークンを使用したグラフAPIリクエストは、そのアプリのレート制限に対してカウントされます。アプリの呼び出しカウントは、1時間のローリング枠で可能な呼び出しの数です。これは次のように計算されます。

Calls within one hour = 200 * Number of Users

ユーザー数は、アプリのデイリーアクティブユーザー数(重複を除く)に基づいて算出します。1日の利用量が少ない日がある場合(週末はアプリの利用が多いが平日は少ない場合など)は、週間および月間のアクティブユーザー数を使用してアプリのユーザー数を算出します。アプリの実際のインストール数にかかわらず、1日あたりの利用が少ないアプリよりも、1日あたりの利用が多いアプリの方が、レート制限が高くなります。

これはユーザーあたりの制限ではなく、アプリからの呼び出しに対する制限であることに注意してください。アプリからの呼び出しの合計数がアプリの上限を超えない限り、個々のユーザーは1時間あたり200件を超える呼び出しをアプリから実行できます。例えば、アプリのユーザーが100人いる場合、アプリは1時間あたり20,000件の呼び出しを実行できます。ただし、その呼び出しのうち19,000件は、最も利用頻度が高い10人のユーザーによるものかもしれません。

ユーザー

ユーザーアクセストークンを使用したグラフAPIリクエストは、そのユーザーの呼び出しカウントに対してカウントされます。ユーザーの呼び出しカウントは、ユーザーが1時間のローリング枠で可能な呼び出しの数です。プライバシーへの配慮から、Facebookはユーザーの実際の呼び出しカウントの数値は公開していません。

ユーザーの呼び出しカウントは複数のアプリにまたがる可能性があることに注意してください。例えば、あるユーザーがApp1からX件、App2からY件の呼び出しをするとします。X+Yがユーザーの呼び出しカウントを超えると、そのユーザーはレート制限を受けます。レート制限が適用されても、アプリの動作に問題があるとは限りません。ユーザーが複数のアプリを使用している場合もあれば、APIを誤用している場合もあります。

ヘッダー

アプリから相当数のリクエストを受信するエンドポイントは、X-App-Usage HTTPヘッダーまたはX-Ad-Account-Usage HTTPヘッダー(v3.3以前の広告API呼び出しの場合)を応答に含めます。ヘッダーには、現在のアプリレート制限の使用状況を記述するJSON形式の文字列が挿入されます。

ヘッダーの内容

キー	値の説明
`call_count`	アプリが1時間のローリング枠で行う呼び出しの割合を表す整数。
`total_cputime`	CPU時間のうち、クエリ処理に割り当てられたパーセンテージを表す整数。
`total_time`	クエリ処理に割り当てられた合計時間の割合を表す整数。

X-Ad-Account-Usageヘッダーの内容

キー	値の説明
`acc_id_util_pct`	レート制限に達するまでの、この広告アカウントで行われた呼び出しのパーセンテージ。
`reset_time_duration`	現在のレート制限を0にリセットするのに必要な時間(秒単位)。
`ads_api_access_tier`	レベルにより、アプリのマーケティングAPIへのアクセスが許可されます。デフォルトでは、アプリは`development_access`レベルです。`Standard_access`では低めのレート制限が有効になります。広告管理スタンダードアクセス機能への「アドバンスアクセス」を申請すれば、高レート制限を取得し、スタンダードレベルを維持することができます。

合計CPU時間

リクエストの処理にかかったCPU時間。total_cputimeが100に達すると、呼び出しがスロットリングされることがあります。

合計時間

リクエストの処理にかかった時間の長さ。total_timeが100に達すると、呼び出しがスロットリングされることがあります。

X-App-Usageヘッダーの値の例

x-app-usage: {
    "call_count": 28,         //Percentage of calls made 
    "total_time": 25,         //Percentage of total time
    "total_cputime": 25       //Percentage of total CPU time
}

X-Ad-Account-Usageヘッダーの値の例

x-ad-account-usage: {
    "acc_id_util_pct": 9.67,   //Percentage of calls made for this ad account.
    "reset_time_duration": 100,   //Time duration (in seconds) it takes to reset the current rate limit score.
    "ads_api_access_tier": 'standard_access'   //Tiers allows your app to access the Marketing API. standard_access enables lower rate limiting.
}

ダッシュボード

アプリダッシュボードには、レート制限を受けたアプリユーザーの数、アプリの現在のアプリレート制限の使用状況、過去7日間の平均アクティビティが表示されます。アプリレート制限カードで[詳細を表示]をクリックし、グラフ上の任意の場所にマウスを重ねると、特定の時点における使用状況の詳細を表示できます。使用状況は呼び出しの量に左右されるため、このグラフに7日間すべてのデータが表示されないことがあります。呼び出しの量が多いアプリほど、より多くの日数のデータが表示されます。

エラーコード

アプリまたはユーザーがレート制限に達すると、そのアプリまたはユーザーが発行するリクエストは失敗し、APIは応答でエラーコードを返します。

スロットリングのエラーコード

エラーコード	説明
`4`	リクエストでトークンが使用されているアプリがレート制限に達したことを示します。
`17`	リクエストでトークンが使用されているユーザーがレート制限に達したことを示します。
`17 with subcode 2446079`	v3.3以前の広告APIリクエストで使用されているトークンがレート制限に達したことを示します。
`32`	ページAPIリクエストでトークンが使用されているユーザーまたはアプリがレート制限に達したことを示します。
`613`	カスタムレート制限に達したことを示します。この問題を解決するには、呼び出している特定のAPIのサポートドキュメントを参照し、適用される可能性があるカスタムレート制限について調べてください。
`613 with subcode 1996`	アプリのAPIリクエスト量に一貫性のない変動が見られたことを示します。このエラーは、APIリクエスト数に影響するような変更を最近実施した場合に発生する可能性があります。

応答の例

{
  "error": {
    "message": "(#32) Page request limit reached",
    "type": "OAuthException",
    "code": 32,
    "fbtrace_id": "Fz54k3GZrio"
  }
}

Facebook安定性スロットリングコード

エラーコード説明

エラーコード	説明
`throttled`	クエリがスロットリングされているかどうか。値: `True`、`False`
`backend_qps`	第1スロットリング要素: `backend_qps`。使用できる値: `actual_score`—このアプリの実際の`backend_qps`。値: `8` `limit`—このアプリの`backend_qps`制限。値: `5` `more_info`—クエリで、大量のバックエンドリクエストを処理することが必要です。送信するクエリの数を少なくするか、期間やオブジェクトIDなどの範囲を狭めることによりクエリを簡素化することをおすすめします。
`complexity_score`	第2スロットリング要素: `complexity_score`。使用できる値: `actual_score`—このアプリの実際の`complexity_score`。値: `0.1` `limit`—このアプリの`complexity_score`制限。値: `0.01` `more_info`— `complexity_score`の値が高い場合、クエリが非常に複雑で、大量のデータが求められることを意味しています。期間を短くしたり、オブジェクトID、指標、内訳などの数を少なくしたりすることによりクエリを簡素化することをおすすめします。大きくて複雑なクエリを複数の小さいクエリに分割し、間にスペースを入れるようにしてください。

throttled

クエリがスロットリングされているかどうか。値: True、False

backend_qps

第1スロットリング要素: backend_qps。使用できる値:

actual_score—このアプリの実際のbackend_qps。値: 8
limit—このアプリのbackend_qps制限。値: 5
more_info—クエリで、大量のバックエンドリクエストを処理することが必要です。送信するクエリの数を少なくするか、期間やオブジェクトIDなどの範囲を狭めることによりクエリを簡素化することをおすすめします。

complexity_score

第2スロットリング要素: complexity_score。使用できる値:

actual_score—このアプリの実際のcomplexity_score。値: 0.1
limit—このアプリのcomplexity_score制限。値: 0.01
more_info— complexity_scoreの値が高い場合、クエリが非常に複雑で、大量のデータが求められることを意味しています。期間を短くしたり、オブジェクトID、指標、内訳などの数を少なくしたりすることによりクエリを簡素化することをおすすめします。大きくて複雑なクエリを複数の小さいクエリに分割し、間にスペースを入れるようにしてください。

ベストプラクティス

制限に達したときは、API呼び出しを停止します。呼び出しを停止しないと、呼び出しカウントが増え続け、呼び出しが再び成功するようになるまでの時間が長くなります。
トラフィックの急増を回避するため、クエリを均等に分散します。
フィルターを使用してデータ応答のサイズを制限し、重複データをリクエストする呼び出しを回避します。
X-App-Usage HTTPヘッダーをチェックして、アプリがどの程度制限に近づいているか、すでに制限に達している場合はいつ呼び出しを再開できるかを確認します。
ユーザーがスロットリングされている場合は、原因がアプリでないことを確認します。ユーザーの呼び出しを減らすか、時間を空けてユーザーの呼び出しをさらに均等に分散します。

ビジネスユースケースのレート制限

すべてのマーケティングAPIリクエストと、システムユーザートークンまたはページアクセストークンを使用したページAPIリクエストは、クエリするエンドポイントに応じて、ビジネスユースケース(BUC)レート制限が適用されます。

マーケティングAPIの場合、同じビジネスユースケース全体の広告アカウントにレート制限が適用されます。例えば、広告管理のビジネスユースケースの場合、すべてのエンドポイントが、同じ広告アカウント内の合計クォータを共有します。特定のエンドポイントがAPIリクエストを多発してスロットリングを起こした場合、同じビジネスユースケースが設定されたほかのエンドポイントでもレート制限エラーが発生します。クォータはアプリのマーケティングAPIアクセスレベルによって異なります。スタンダードアクセスのマーケティングAPIレベルは、開発アクセスのマーケティングAPIレベルよりも多くのクォータを持ちます。デフォルトでは、新規のアプリは開発レベルになっています。より多くのレート制限クォータを得るためにアップグレードする必要がある場合は、アプリレビューで広告管理スタンダードアクセスのアドバンスアクセスにアップグレードしてください。

広告インサイト
広告管理
カタログ
カスタムオーディエンス
Instagramプラットフォーム
リード獲得

Messenger
ページ
Spark ARコマースエフェクトの管理
WhatsApp Business管理API

広告インサイト

アプリによる広告インサイトAPIへのリクエストは、呼び出しカウント、合計CPU時間、合計時間などのアプリのレート制限指標にカウントされます。アプリの呼び出しカウントは、1時間のローリング枠で行うことのできる呼び出しの数です。これは次のように計算されます。

広告管理スタンダードアクセス機能へのスタンダードアクセスを持つアプリの場合

Calls within one hour = 600 + 400 * Number of Active ads - 0.001 * User Errors

広告管理スタンダードアクセス機能へのアドバンスアクセスを持つアプリの場合は、次のようになります。

Calls within one hour = 190000 + 400 * Number of Active ads - 0.001 * User Errors

アクティブ広告数は、各広告アカウントで現在掲載中の広告の数です。ユーザーエラー数は、APIの呼び出し時に受信したエラーの数です。レート制限を引き上げるには、広告管理スタンダードアクセス機能を申請することができます。

レート制限には、1時間のローリング枠の合計CPU時間と合計ウォール時間の制限もあります。詳細は、HTTP X-Business-Use-Case ヘッダー total_cputimeとtotal_timeをチェックしてください。

レート制限のエラーを受け取る場合は、X-Business-Use-Caseヘッダーのestimated_time_to_regain_accessを参照して、推定ブロック時間を確認してください。

広告管理

アプリから広告管理APIへのリクエストは、呼び出しカウント、合計CPU時間、合計時間などのアプリのレート制限指標にカウントされます。アプリの呼び出しカウントは、1時間のローリング枠で行うことのできる呼び出しの数です。これは次のように計算されます。

広告管理スタンダードアクセス機能へのスタンダードアクセスを持つアプリの場合は、次のようになります。

Calls within one hour = 300 + 40 * Number of Active ads

広告管理スタンダードアクセス機能へのアドバンスアクセスを持つアプリの場合は、次のようになります。

Calls within one hour = 100000 + 40 * Number of Active ads

アクティブ広告数は、各広告アカウントの広告の数です。

レート制限には、1時間のローリング枠の合計CPU時間と合計実行時間の制限もあります。詳細は、HTTP X-Business-Use-Case ヘッダー total_cputimeとtotal_timeをチェックしてください。

レート制限のエラーを受け取る場合は、X-Business-Use-Caseヘッダーのestimated_time_to_regain_accessを参照して、推定ブロック時間を確認してください。

カタログ

カタログバッチ

アプリによるリクエストは、アプリが、カタログIDあたり1時間のローリング枠で実行できる呼び出しカウント、合計CPU時間、合計時間などのレート制限指標にカウントされます。これは次のように計算されます。

Calls within one hour = 200 + 200 * log2(unique users)

ユニークユーザーは、過去28日間における、インテントを持った(すべてのカタログ上の)ビジネスのユニークユーザーの数です。カタログの商品を見るユーザーが多いほど、より多くの呼び出しクォータが割り当てられます。

呼び出しのタイプ	エンドポイント
POST	/{catalog_id}/items_batch
POST	/{catalog_id}/localized_items_batch
POST	/{catalog_id}/batch

カタログ管理

アプリが行うリクエストはカウントされ、各カタログIDの1時間のローリング枠内でアプリが呼び出せる数が減っていきます。次のように計算されます。

Calls within one hour = 20,000 + 20,000 * log2(unique users)

この数式がさまざまなカタログのエンドポイントに適用されます。

現在のレート使用状況を取得する方法については、ヘッダーをご覧ください。

レート制限のエラーを受け取る場合は、X-Business-Use-Caseヘッダーのestimated_time_to_regain_accessを参照して、推定ブロック時間を確認してください。

カスタムオーディエンス

アプリからカスタムオーディエンスAPIへのリクエストは、呼び出しカウント、合計CPU時間、合計時間などのアプリのレート制限指標にカウントされます。アプリの呼び出しカウントは、1時間のローリング枠で実行できる呼び出しの数です。以下のように計算されますが、700,000を超えることはありません。

広告管理スタンダードアクセス機能へのスタンダードアクセスを持つアプリの場合

Calls within one hour = 5000 + 40 * Number of Active Custom Audiences

広告管理スタンダードアクセス機能へのアドバンスアクセスを持つアプリの場合は、次のようになります。

Calls within one hour = 190000 + 40 * Number of Active Custom Audiences

アクティブカスタムオーディエンスの数は、各広告アカウントのアクティブなカスタムオーディエンスの数です。

レート制限のエラーを受け取る場合は、X-Business-Use-Caseヘッダーのestimated_time_to_regain_accessを参照して、推定ブロック時間を確認してください。

Instagramプラットフォーム

Calls to the Instagram Platform endpoints, excluding messaging, are counted against the calling app's call count. An app's call count is unique for each app and app user pair, and is the number of calls the app has made in a rolling 24 hour window. It is calculated as follows:

Calls within 24 hours = 4800 * Number of Impressions

The Number of Impressions is the number of times any content from the app user's Instagram professional account has entered a person's screen within the last 24 hours.

Notes

The Instagram Basic Display API uses Platform Rate Limits.

Business Discovery and Hashtag Search API are subject to Platform Rate Limits.

Messaging Rate Limits

Calls to the Instagram messaging endpoints are counted against the number of calls your app can make per Instagram professional account and the API used.

Conversations API

Your app can make 2 calls per second per Instagram professional account.

Private Replies API

Your app can make 100 calls per second per Instagram professional account for private replies to Instagram Live comments
Your app can make 750 calls per hour per Instagram professional account for private replies to comments on Instagram posts and reels

Send API

Your app can make 100 calls per second per Instagram professional account for messages that contain text, links, reactions, and stickers
Your app can make 10 calls per second per Instagram professional account for messages that contain audio or video content

リード獲得

アプリからリード獲得APIに対して行われるリクエストは、アプリの呼び出しカウントに対してカウントされます。アプリの呼び出しカウントは、24時間のローリング枠で可能な呼び出しの数です。これは次のように計算されます。

Calls within 24 hours = 4800 * Leads Generated

獲得リード数は、過去90日間にこの広告アカウントでページごとに獲得されたリードの数です。

Messengerプラットフォーム

Messengerプラットフォームのレート制限は、使用するAPIや、場合によってはメッセージのコンテンツに応じて異なります。

Messenger API

アプリが行うリクエストは、24時間のローリング枠におけるアプリの最大呼び出し可能数に制限され、次のように計算されます。



Calls within 24 hours = 200 * Number of Engaged Users

この「Number of Engaged Users」は、ビジネスがMessengerでメッセージを送信できる人の数を指します。

Instagram用Messenger API

アプリが行うリクエストは、Instagramプロアカウントあたりのアプリの最大呼び出し可能数に制限され、使用するAPIに応じて次のように異なります。

コンバージョンAPI

Instagramプロアカウントあたり毎秒2回の呼び出し

送信API

テキスト、リンク、リアクション、スタンプが含まれているメッセージの場合、Instagramプロアカウントあたり毎秒100回の呼び出し
音声または動画コンテンツが含まれているメッセージの場合、Instagramプロアカウントあたり毎秒10回の呼び出し

プライベート返信API

Instagram Liveコメントに対するプライベート返信の場合、Instagramプロアカウントあたり毎秒100回の呼び出し
Instagramの投稿およびリールへのコメントに対するプライベート返信の場合、Instagramプロアカウントあたり毎時750回の呼び出し

ページ

ページのレート制限は、使用されるトークンのタイプに応じて、プラットフォームレート制限またはBUCレート制限のロジックに従います。ページアクセストークンまたはシステムユーザーアクセストークンを使用して行われるすべてのページAPI呼び出しのレート制限は、下記の方法で計算されます。アプリアクセストークンまたはユーザーアクセストークンを使用して行われるすべての呼び出しは、アプリレート制限またはユーザーレート制限に従います。

ページアクセストークンまたはシステムユーザーアクセストークンを使用してアプリからページAPIに対して行われるリクエストは、アプリの呼び出しカウントに対してカウントされます。アプリの呼び出しカウントは、24時間のローリング枠で可能な呼び出しの数です。これは次のように計算されます。

Calls within 24 hours = 4800 * Number of Engaged Users

利用ユーザー数は、そのページを利用したユーザーの24時間あたりの数です。

ユーザーアクセストークンまたはアプリアクセストークンを使用してアプリからページAPIに対して行われるリクエストは、プラットフォームレート制限のロジックに従います。

ページの公開コンテンツへのアクセス機能を使用する際にレート制限の問題を回避するため、システムユーザーアクセストークンを使用することをおすすめします。

Spark ARコマースエフェクトの管理

アプリがコマースエンドポイントに対して実行するリクエストは、アプリの呼び出しカウントとしてカウントされます。アプリの呼び出しカウントは、1時間のローリング枠で可能な呼び出しの数です。これは次のように計算されます。

Calls within one hour = 200 + 40 * Number of Catalogs

カタログ数は、アプリで管理するすべてのコマースアカウントにおけるカタログの合計数です。

Threads

Calls to the Threads API are counted against the calling app's call count. An app's call count is unique for each app and app user pair and is the number of calls the app has made in a rolling 24-hour window. It is calculated as follows:

Calls within 24 hours = 4800 * Number of Impressions

The Number of Impressions is the number of times any content from the app user's Threads account has entered a person's screen within the last 24 hours. Rate limiting may also be subject to total CPU time per day:

720000 * number_of_impressions for total_cputime 

      2880000 * Number of Impressions for total_time

Note: The minimum value for impressions is 10 (so if the impressions is less than 10 we default to 10).

WhatsApp Business管理API

アプリからWhatsApp Business管理APIに対してなされるリクエストは、アプリのカウントに含まれます。アプリの呼び出しカウントは、1時間のローリング枠で可能な呼び出しの数です。次のWhatsApp Business管理APIでは、デフォルトで、1アプリあたり、WhatsApp Businessアカウント(WABA)ごとに1時間あたり200回の呼び出しを実施できます。少なくとも1つの電話番号が登録されているアクティブなWABAの場合、1アプリあたり、アクティブなWABAごとに1時間あたり5000件の呼び出しが可能です。

呼び出しのタイプ	エンドポイント
`GET`	`/{whatsapp-business-account-id}`
`GET`、`POST`、`DELETE`	`/{whatsapp-business-account-id}/assigned_users`
`GET`	`/{whatsapp-business-account-id}/phone_numbers`
`GET`、`POST`、`DELETE`	`/{whatsapp-business-account-id}/message_templates`
`GET`、`POST`、`DELETE`	`/{whatsapp-business-account-id}/subscribed_apps`
`GET`	`/{whatsapp-business-account-to-number-current-status-id}`

以下の融資限度額APIの場合、1アプリ当たり、1時間に5000回の呼び出しが可能です。

呼び出しのタイプ	エンドポイント
`GET`	`/{business-id}/extendedcredits`
`POST`	`/{extended-credit-id}/whatsapp_credit_sharing_and_attach`
`GET`と`DELETE`	`/{allocation-config-id}`
`GET`	`/{extended-credit-id}/owning_credit_allocation_configs`

レート制限に達することがないようにするため、Webhooksを使うことによって、メッセージテンプレート、電話番号、WABAのステータスの更新を常に把握しておくことをおすすめします。

現在のレート使用率を知る方法について詳しくは、ヘッダーをご覧湯ください。

ヘッダー

BUCロジックのレート制限を受けるアプリによるすべてのAPI応答には、X-Business-Use-Case-Usage HTTPヘッダー(v3.3以前の広告API呼び出しの場合)と、現在のアプリレート制限の使用状況を記述するJSON形式の文字列が含まれます。このヘッダーは、1つの呼び出しで最大32個のオブジェクトを返すことができます。

X-Business-Use-Case-Usageヘッダーの内容

エラーコード	値の説明
`business-id`	API呼び出しを行うトークンに関連付けられているビジネスのID。
`call_count`	アプリが1時間のローリング枠で可能な呼び出しの割合を表す整数。
`estimated_time_to_regain_access`	呼び出しがスロットリングされなくなるまでの時間(分単位)。
`total_cputime`	CPU時間のうち、クエリ処理に割り当てられたパーセンテージを表す整数。
`total_time`	合計時間のうち、クエリ処理に割り当てられたパーセンテージを表す整数。
`type`	適用されるレート制限のタイプ。次のいずれかの値を指定できます: `ads_insights`、`ads_management`、`custom_audience`、`instagram`、`leadgen`、`messenger`、`pages`。
`ads_api_access_tier`	`ads_insights`および`ads_management`タイプにのみ使用します。レベルにより、アプリのマーケティングAPIへのアクセスが許可されます。デフォルトでは、アプリは`development_access`レベルです。`Standard_access`では低めのレート制限が有効になります。広告管理スタンダードアクセス機能への「アドバンスアクセス」を申請すれば、高レート制限を取得し、スタンダードレベルを維持することができます。

合計CPU時間

リクエストの処理にかかったCPU時間。total_cputimeが100に達すると、呼び出しがスロットリングされることがあります。

合計時間

リクエストの処理にかかった時間の長さ。total_timeが100に達すると、呼び出しがスロットリングされることがあります。

広告APIアクセスレベル

ads_insightsおよびads_managementタイプにのみ使用します。レベルにより、アプリのマーケティングAPIへのアクセスが許可されます。デフォルトでは、アプリはdevelopment_accessレベルです。Standard_accessでは低めのレート制限が有効になります。広告管理スタンダードアクセス機能への「アドバンスアクセス」を申請すれば、高レート制限を取得し、スタンダードレベルを維持することができます。

X-Business-Use-Case-Usageヘッダーの値の例

x-business-use-case-usage: {
    "{business-object-id}": [
        {
            "type": "{rate-limit-type}",           //Type of BUC rate limit logic being applied.
            "call_count": 100,                     //Percentage of calls made. 
            "total_cputime": 25,                   //Percentage of the total CPU time that has been used.
            "total_time": 25,                      //Percentage of the total time that has been used.   
            "estimated_time_to_regain_access": 19,  //Time in minutes to regain access.
            "ads_api_access_tier": "standard_access"  //Tiers allows your app to access the Marketing API. standard_access enables lower rate limiting.
        }
    ],      
    "66782684": [
        {
            "type": "ads_management",
            "call_count": 95,
            "total_cputime": 20,
            "total_time": 20,
            "estimated_time_to_regain_access": 0,
            "ads_api_access_tier": "development_access" 
        }
    ],
    "10153848260347724": [
        {
            "type": "ads_insights",
            "call_count": 97,
            "total_cputime": 23,
            "total_time": 23,
            "estimated_time_to_regain_access": 0,
            "ads_api_access_tier": "development_access"
        }
    ],
    "10153848260347724": [
        {
            "type": "pages",
            "call_count": 97,
            "total_cputime": 23,
            "total_time": 23,
            "estimated_time_to_regain_access": 0
        }
    ],
...
}

エラーコード

アプリがビジネスユースケースレート制限に達すると、それ以降アプリが発行するリクエストは失敗し、APIは応答でエラーコードを返します。

エラーコード	BUCレート制限のタイプ
`error code 80000, error subcode 2446079`	広告インサイト
`error code 80004, error subcode 2446079`	広告管理
`error code 80003, error subcode 2446079`	カスタムオーディエンス
`error code 80002`	Instagram
`error code 80005`	リード獲得
`error code 80006`	Messenger
`error code 32`	ユーザーアクセストークンを使用して行われるページ呼び出し
`error code 80001`	ページアクセストークンまたはシステムユーザーアクセストークンを使用して行われるページ呼び出し
`error code 17, error subcode 2446079`	広告インサイトを除くV3.3以前の広告API
`error code 80008`	WhatsApp Business管理API
`error code 80014`	カタログバッチ
`error code 80009`	カタログ管理

エラーコードメッセージの例

{   
"error": {      
    "message": "(#80001) There have been too many calls to this Page account. Wait a bit and try again. For more info, please refer to https://developers.facebook.com/docs/graph-api/overview/rate-limiting.",      
    "type": "OAuthException",      
    "code": 80001,      
    "fbtrace_id": "AmFGcW_3hwDB7qFbl_QdebZ"   
    }
}

ベストプラクティス

制限に達したときは、API呼び出しを停止します。呼び出しを停止しないと、呼び出しカウントが増え続け、呼び出しが再び成功するようになるまでの時間が長くなります。
X-Business-Use-Case-Usage HTTPヘッダーをチェックして、広告アカウントがどの程度制限に近づいているか、いつ呼び出しを再開できるかを確認します。
エラーコードとAPIエンドポイントを確認し、スロットリングタイプを確かめます。
別の広告アカウントに切り替え、しばらくしてからこのアカウントに戻ってきます。
既存の広告を変更するよりも、新しい広告を作成することをおすすめします。
送信トラフィックの急増を回避するため、2つの時間間隔にクエリを均一に分散させます。
フィルターを使用してデータ応答のサイズを制限し、重複データをリクエストする呼び出しを回避します。

よくある質問

API呼び出しはどのようにカウントされますか？

個々のAPIリクエストではなく、すべての呼び出しがレート制限の対象としてカウントされます。例えば、複数のIDを指定して単一のAPIリクエストを実行できますが、IDごとに1つのAPI呼び出しとしてカウントされます。

このカウント方法の例を次の表に示します。

リクエストの例 API呼び出しの数

リクエストの例	API呼び出しの数
`GET https://graph.facebook.com/photos?ids=4` `GET https://graph.facebook.com/photos?ids=5` `GET https://graph.facebook.com/photos?ids=6`	3
`GET https://graph.facebook.com/photos?ids=4,5,6`	3

GET https://graph.facebook.com/photos?ids=4

GET https://graph.facebook.com/photos?ids=5

GET https://graph.facebook.com/photos?ids=6

GET https://graph.facebook.com/photos?ids=4,5,6

可能であれば、1つのAPIリクエストに複数のIDを指定することを強くおすすめします。それにより、API応答のパフォーマンスが向上します。

スクレイパーを作成しています。どのような点に注意すべきでしょうか？

データをスクレイピングするサービスを開発している場合は、スクレイピングに関する規約をご覧ください。