Cato API のレート制限は、各クエリ、各アカウントベースで適用されます。 これは、各クエリには個別のカウンターがありますが、該当アカウントへのクエリを行うすべてのAPIキーに適用されます。 したがって、異なるユーザーが別々のクエリを行っても、お互いに影響はありません。 しかし、異なるユーザーが同じクエリを行う場合、これらのクエリはレート制限の目的で同じカウンターの対象となり、1人のユーザーのクエリが他のユーザーに影響を与える可能性があります。
Cato API のバックエンドは高可用性で柔軟性があるため、レート制限は絶対的な最大値ではなく、保証された最小値となります。 例えば、auditFeed クエリのレート制限は1分間に5つです。これはアカウントが60秒ごとに少なくとも5回 auditFeed を呼び出せることを意味します。 実際には、顧客がこのクエリをより頻繁に呼び出すことも可能ですが、無制限の呼び出しに対する保証された最小レートは1分間に5回です。 それにもかかわらず、アカウント全体のカウンターも存在するため、5人の異なるユーザーが同時に auditFeed をクエリした場合、レート制限の影響を受けないことを保証するには、各ユーザーは60秒ごとに1回しかクエリを呼び出せません。
CatoのGitHubアカウントは、待機して5秒後に再試行することでレート制限をうまく処理するサンプルPython scriptsを含んでいます。 顧客も自分のAPIスクリプトで同様の戦略を採用できます。
クエリがレート制限に関連する問題に遭遇した場合、数分待ってからさらに追加のAPIクエリ送信を再開することをお勧めします。
一般的なAPI制限レート
API 呼び出しは、以下のクエリとミューテーションを除き、1分あたり120のレート制限があります：
クエリ例外
次のクエリAPIは例外であり、1分あたり120のレート制限はありません：
accountMetrics: 15/分
accountSnapshot: 1/秒 (30/分)
appStatsTimeSeries: 80/分
auditFeed: 5/分
entityLookup: 30/分 (1500/5時間)
eventsFeed: 100/分
ミューテーション例外
次のミューテーション API は例外であり、1分あたり120のレート制限はありません：
accountManagement.addAccount: 10/分
accountManagement.removeAccount: 5/分
policy.appTenantRestriction.publishPolicyRevision: 3/分 (20/時)
policy.dynamicIpAllocation.publishPolicyRevision: 3/分 (20/時)
policy.internetFirewall.publishPolicyRevision: 3/分 (20/時)
policy.pacFile.publishPolicyRevision: 3/分 (20/時)
policy.remotePortFwd.publishPolicyRevision: 3/分 (20/時)
policy.socketLanFirewall.publishPolicyRevision: 3/分 (20/時)
policy.socketLanNetwork.publishPolicyRevision: 3/分 (20/時)
policy.wanFirewall.publishPolicyRevision: 3/分 (20/時)
policy.wanNetwork.publishPolicyRevision: 3/分 (20/時)
policy.ztnaAlwaysOn.publishPolicyRevision: 3/分 (20/時)
sandbox.uploadFile: 5/5 分