レート制限

デフォルト制限

両方のウィンドウはすべてのリクエストで評価されます。狭いウィンドウ (60/分) は短時間のバーストを制御し、時間ウィンドウは持続的な負荷を制御します。いずれかのウィンドウを超過した場合、リクエストは429 Too Many Requestsで拒否されます — どのウィンドウが作動したかを調べる必要はなく、Retry-Afterヘッダーに従ってください。

拒否時のレスポンス

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Window: per_minute
X-RateLimit-Limit: 60

{ "error": "rate_limited" }

Retry-Afterは常に秒の整数カウントです — 次のリクエストが成功するまでの最小の安全な遅延です。X-RateLimit-Limitは作動したウィンドウの上限を反映します。

スライディングウィンドウと固定ウィンドウ

1分あたりのウィンドウは暦上の分 (UTC) に固定されています。13:42:59でのリクエストと13:43:01でのリクエストは別々のバケットに入ります。1時間あたりのウィンドウは、過去60分間の真のスライディング集約です。これは、通常使用時に分上限を繰り返し超えていない限り、時間上限に達することはないことを意味します。

推奨されるクライアント動作

• 429の場合、少なくともRetry-After秒スリープし、1回再試行してください。
• ジッタを使用してください: 多くのワーカーが同時に制限に達した場合のサンダリングハードを避けるためにretryAfter + random(0, 5)秒。
• バッチサイズを制御できる場合は、キーあたり毎分50リクエスト以下で実行してください — 上限の安全圏内に収まります。
• 大量ジョブ (データエクスポート、大量ユーザープロビジョニング) では、1つのキーを共有するのではなく、ワーカーごとに1つのキーを発行してください。
• 429をアラート対象のエラーとして扱わないでください。指数関数的バックオフ後の繰り返しの失敗のみアラートしてください。

再試行パターン

ジッタ付きでRetry-Afterを尊重する最小のNode例:

async function call(path) {
  for (let attempt = 0; attempt < 4; attempt++) {
    const res = await fetch(`https://api.limeplate.com${path}`, {
      headers: { Authorization: `Bearer ${process.env.SCH_API_KEY}` },
    });
    if (res.status !== 429) return res;
    const wait = parseInt(res.headers.get('Retry-After') || '60', 10);
    const jitter = Math.floor(Math.random() * 5);
    await new Promise(r => setTimeout(r, (wait + jitter) * 1000));
  }
  throw new Error('exhausted retries on 429');
}

より高いクォータのリクエスト

ほとんどの統合はデフォルト制限内で快適に動作します。ワークロードが本当に高い上限を必要とする場合 — 例えば、10,000ユーザーの進捗を取得する夜間Lookerリフレッシュ — APIキー名、統合の目的、想定するピーク時のリクエスト/分を添えてsupport@securecodinghub.comまでお問い合わせください。トークンをローテーションすることなく、キーあたりの制限を引き上げることができます。

レート制限されないもの

SecureCodingHubから受け入れるインバウンドWebhook配信は、当社側ではレート制限されません。エンドポイントに送信するアウトバウンドWebhook配信は、Webhookで文書化された別の再試行スケジュールに従います。