Elido は API をワークスペース単位ではなく、キー単位でレート制限します。つまり、構築した各統合は、他の統合を枯渇させることなく、独自の制限まで利用できます。この記事では、プランごとの制限、確認すべきヘッダー、およびクリーンにバックオフする方法について説明します。
制限値#
キーあたりの持続的な制限：
| プラン | 1分あたり | バースト |
|---|---|---|
| Free | 60 | 120 |
| Pro | 600 | 1200 |
| Business | 6000 | 12000 |
バースト（Burst）は、10秒間のウィンドウ内で一時的に超過できる量です。持続的（Sustained）は、バケットが補充される定常状態の上限です。
エンドポイントごとの制限はありません。GET /v1/links は POST /v1/links と同じようにカウントされます。唯一の例外は以下の通りです：
POST /v1/bulk-import— 1つのワークスペースにつき、同時にアクティブなインポートは5つまで。POST /v1/linksで既存のスラッグと衝突するカスタムスラッグを使用した場合 — これらもカウントされますが、衝突時にスロットは返却されません。GET /v1/analytics/timeseriesでinterval=secondを指定した場合 — 基盤となる ClickHouse クエリが重いため、Business プランでも 60/分に制限されます。
レスポンスヘッダー#
すべての API レスポンスには以下が含まれます：
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 587
X-RateLimit-Reset: 1747386240
X-RateLimit-Reset は、バケットが満杯まで補充される時期を示す Unix タイムスタンプです。固定の遅延ではなく、これを使用してリトライをスケジュールしてください。
429 エラーの形式#
制限を超えると以下のようになります：
HTTP/1.1 429 Too Many Requests
Retry-After: 12
Content-Type: application/json
{
"error": "rate_limited",
"message": "API rate limit exceeded for this key",
"retry_after_seconds": 12
}
Retry-After は秒単位です。その時間待機してからリトライしてください。SDK はジッター（ゆらぎ）を伴ってこれを自動的に行います。生の HTTP クライアントを作成している場合は、同様の処理を実装してください。
バックオフ戦略#
API を集中的に使用する場合（一回限りの一括ジョブ、バックフィルなど）、クライアントのペースをバーストではなく定常状態の制限に合わせて調整してください。単純なループではバースト上限に達し、その後 50 秒間停止し、再びバーストに達するという動作になり、ペースを調整するよりも平均的なパフォーマンスが悪くなります。
疑似コード：
const limit = 600; // per minute
const delayMs = (60 * 1000) / limit; // 100ms between requests
for (const item of items) {
await fetch(...);
await sleep(delayMs);
}
このパターンは、429 を発生させることなく制限を 100% 活用します。
並行性#
並行リクエストはバケットを共有します。Pro プラン（600/分）でワーカープールから 100 件の並列リクエストを送信した場合、最初の 100 件は即座に成功しますが、その後バケットは 10/秒の速さで補充されます。ワーカープールはキューの深さではなく、持続的なレートをターゲットにする必要があります。
キー単位 vs IP 単位#
バケットは IP 単位ではなく、キー単位です。10 台のマシンから同じキーを使用している場合、その 10 台で制限を共有します。10 倍の余裕が必要な場合は、マシンごとにキーを発行してください。
IP レイヤーには、暴走したクライアントを阻止することのみを目的とした、非常に寛大な別の制限（10,000/分/IP）があります。通常の使用でこれに達することはありません。達した場合は、ボディに "error": "ip_rate_limited" を含む 429 レスポンスが返されます。
べき等性キーによるバイパスは不可#
同じ Idempotency-Key を繰り返し送信しても、各リクエストはバケットに対してカウントされます。基盤となる処理を行わずにキャッシュされたレスポンスを返すことはできますが、カウントは増加します。リトライ戦略としてべき等性キーでループさせないでください。
制限の引き上げ#
ユースケースで持続的に 6000/分以上が必要な場合は、以下の情報を添えて support@elido.app までメールでお問い合わせください。
- ワークスペース ID。
- 統合の名前。
- 期待される定常状態およびピーク時のリクエストレート。
- 使用するエンドポイント（重いエンドポイントのキャパシティプランニングのため）。
契約に基づき、エンタープライズのお客様にはキー単位の制限緩和を提供しており、通常 1 営業日以内に対応します。
トラブルシューティング#
以前は動作していたキーで突然 429 が発生する。 コードがループし始めた（最も一般的）か、ワークスペース内の他の誰かが同じキーを使用し始めた可能性があります。ダッシュボードの API キーの Usage タブで、分ごとのグラフを確認してください。
一日の最初のリクエストで 429 が発生する。 Free ティアのバケットは、UTC の午前 0 時ではなく、ローリングウィンドウでリセットされます。昨日 23:59 に制限までテストし、00:01 にまだ完全に補充されていない場合、最初のバーストは依然としてレート制限されます。60 秒待ってください。
X-RateLimit-Remaining が負の値になる。 バーストのオーバーシュートです。その数値は負の方向にどれだけ進んでいるかを示しています。60/limit を掛けることで、ゼロに戻るまでの秒数を確認できます。