속도 제한

기본 한도

두 윈도우는 모든 요청에서 평가됩니다. 더 좁은 윈도우(분당 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은 트립된 윈도우의 상한을 반영합니다.

슬라이딩 윈도우 대 고정 윈도우

분당 윈도우는 달력 분(UTC)에 고정됩니다. 13:42:59의 요청과 13:43:01의 요청은 다른 버킷에 속합니다. 시간당 윈도우는 지난 60분에 대한 실제 슬라이딩 집계입니다. 즉, 일반 사용 중에는 분당 한도를 반복적으로 트립하지 않는 한 시간당 한도를 트립할 가능성이 없습니다.

권장 클라이언트 동작

• 429에서 최소 Retry-After초 동안 대기한 후 한 번 재시도합니다.
• 지터를 사용하세요: 많은 워커가 한도에 동시에 도달할 때 thundering herd를 방지하려면 retryAfter + random(0, 5)초입니다.
• 배치 크기를 제어할 수 있다면 키당 분당 50회 요청을 초과하지 마세요 — 안전하게 한도 아래에 있게 됩니다.
• 대용량 작업(데이터 내보내기, 대량 사용자 프로비저닝)의 경우, 단일 키를 공유하지 않고 워커당 하나의 키를 발급하세요.
• 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로부터 수락하는 인바운드 웹훅 전달은 우리 쪽에서 속도 제한되지 않습니다. 우리가 엔드포인트로 보내는 아웃바운드 웹훅 전달은 웹훅 아래에 문서화된 별도의 재시도 일정을 따릅니다.