Polymarket API 요청 한도: 완벽 레퍼런스

Polymarket에 초당 몇 개의 요청을 보낼 수 있을까?라는 간단한 질문에 답하려 해 본 적이 있다면, 간단한 답이 없다는 것을 알게 되었을 겁니다. 한도는 서로 다른 두 시스템에 나뉘어 있고, 각기 다른 페이지에 공개되어 있으며, 대부분의 API가 쓰는 초당 또는 분당 수치가 아니라 10초 구간으로 표현됩니다.

특정 경로의 한도는 Polymarket API 레퍼런스의 엔드포인트별 페이지에서도 확인할 수 있습니다.

이 페이지는 문서화된 모든 한도를 한곳에 모으고, 두 시스템을 설명하고, 한도를 넘었을 때 실제로 무슨 일이 일어나는지 보여줍니다. 모든 수치는 Polymarket 공식 문서에서 가져왔으며 2026년 9월 기준입니다.

서로 다른 두 가지 요청 한도 시스템

대부분의 개발자가 여기서 걸립니다. Polymarket은 서로 독립적인 두 개의 제한 장치를 운영하며, 하나의 한도 아래에 있다고 해서 다른 하나로부터 보호받지 못합니다.

Gamma API 요청 한도

Base URL https://gamma-api.polymarket.com. Gamma는 마켓과 이벤트 메타데이터를 제공합니다. 플랫폼을 처음 살펴볼 때 대부분 가장 먼저 호출하는 엔드포인트들입니다.

Data API 요청 한도

Base URL https://data-api.polymarket.com. 포지션, 거래 내역, 포트폴리오 데이터를 다룹니다. 이 API가 Gamma나 CLOB보다 얼마나 엄격한지 주목하세요. 일반 한도는 10초에 1,000회로 Gamma의 4분의 1입니다.

Data API v2

Data API v2는 2026년 9월 4일 https://data-api.polymarket.com/v2에 출시되었으며 자체 한도를 가집니다. v1도 여전히 동작하지만 동결되었습니다. 새 엔드포인트와 필드는 v2에만 추가됩니다.

CLOB API 요청 한도

Base URL https://clob.polymarket.com. 오더북 그 자체입니다. CLOB은 Polymarket API 중 일반 허용량이 가장 높지만(10초에 9,000회), 한도가 크게 다른 네 그룹으로 나뉩니다.

일반

마켓 데이터

여기서 주목할 패턴은 단수형 엔드포인트는 10초에 1,500회, 복수형 배치 엔드포인트는 10초에 500회라는 점입니다. 배치 호출 한 번이 여러 토큰을 처리한다는 것을 기억하기 전까지는 하향 조정처럼 보입니다. 배치는 요청당 3배 비싸지만 호출마다 훨씬 많은 일을 합니다. 항상 /book 루프보다 /books를 선택하세요.

원장

인증

거래: 버스트와 지속

거래 엔드포인트만 Cloudflare 한도가 두 개입니다. 짧은 급증을 위한 버스트 한도와 10분 단위로 측정하는 지속 한도입니다. 두 한도 모두 지켜야 합니다.

10초에 250회인 DELETE /cancel-all은 짚고 넘어갈 가치가 있습니다. 재호가 주기마다 cancel-all을 호출하는 마켓 메이커는 이 한도를 빠르게 소진하며, 10분에 6,000회라는 지속 한도는 평균 초당 cancel-all 호출 10회에 불과합니다.

Bridge, Relayer, 그 밖의 모든 것

서명자별 토큰 버킷 (CLOB 거래)

Cloudflare와 별도로, Polymarket은 CLOB 주문 및 취소 요청을 서명자별 토큰 버킷으로 평가합니다. 각 서명자 주소는 주문 버킷과 취소 버킷을 하나씩 가지며, 한쪽을 소비해도 다른 쪽에는 영향이 없습니다. Cloudflare 계층과 달리 이 한도를 넘으면 실제 429가 반환됩니다.

요청은 각각 1단위로 세어지는 것이 아니라 토큰을 소비합니다:

거래량 등급

버킷 크기는 최근 30일 동안의 메이커 지갑 누적 거래량에 따라 정해집니다. 등급 배정은 3시간마다 갱신됩니다.

전체 버스트가 얼마나 지속되는지는 burst_seconds = burst / rate_per_sec로 계산하세요. Standard 서명자라면 60 / 40, 즉 최고 속도로 1.5초 동안 주문을 제출한 뒤 초당 40회의 충전 속도로 제한됩니다.

요청 한도 헤더 읽기

서명자별 제한 장치는 평가한 모든 요청에 헤더를 반환합니다. 추가 API 호출 없이 예산을 모니터링하는 가장 저렴한 방법입니다.

429를 제대로 처리하기

올바른 재시도 전략은 어떤 제한 장치에 걸렸는지에 따라 다르며, 잘못하면 상황이 더 나빠집니다. Retry-After가 있으면 따르고, 없으면 지터를 포함한 지수 백오프로 대체하세요. 지터는 중요합니다. 지터가 없으면 모든 워커가 같은 순간에 재시도해 곧바로 다시 한도에 걸립니다.

const MAX_RETRIES = 5;

async function polyFetch(url: string, init?: RequestInit): Promise<Response> {
  for (let attempt = 0; attempt <= MAX_RETRIES; attempt++) {
    const res = await fetch(url, init);

    // Watch the budget even on success — this is your early warning.
    const remaining = res.headers.get("Poly-RateLimit-Remaining");
    if (remaining !== null && Number(remaining) < 10) {
      console.warn(`Low token budget: ${remaining} (tier ${res.headers.get("Poly-RateLimit-Tier")})`);
    }

    // Warning mode: not rejected yet, but it would have been.
    if (res.headers.get("Poly-RateLimit-Warning") === "true") {
      console.warn("Request would be rejected under live enforcement — slow down.");
    }

    if (res.status !== 429) return res;
    if (attempt === MAX_RETRIES) return res;

    // Prefer the server's own answer, else exponential backoff.
    const retryAfter = res.headers.get("Retry-After");
    const baseMs = retryAfter
      ? Number(retryAfter) * 1000
      : Math.min(2 ** attempt * 250, 8000);

    // Full jitter — spreads a fleet of workers out instead of resynchronising them.
    await new Promise((r) => setTimeout(r, Math.random() * baseMs));
  }

  throw new Error("unreachable");
}

설계 단계에서 한도 아래에 머물기

• 루프 대신 배치를 사용하세요. /book 호출 50번 대신 /books 호출 한 번이면, 10초에 1,500회 예산에서 50회를 쓰는 대신 10초에 500회 예산에서 1회만 씁니다. 여유가 17배 늘어납니다.
• 메타데이터를 캐시하세요. /markets의 마켓 메타데이터는 마켓 수명 동안 거의 바뀌지 않지만, /markets는 10초에 300회로 Gamma에서 가장 엄격한 한도를 가집니다. 한 번 가져와 캐시하고 반복 루프에서 다시 요청하지 마세요.
• 실시간 상태에는 WebSocket을 사용하세요. 타이머로 /book을 폴링하는 것이 요청 예산을 소모하는 가장 흔한 방법입니다. 대신 스트림을 구독하고 서버가 변경 사항을 푸시하게 하세요.
• 예약 작업에 지터를 추가하세요. 모든 워커가 정확히 정각에 깨어나면 평균 요청률을 훨씬 넘는 동시 급증이 생깁니다. 시작 오프셋을 무작위로 정하세요.
• 오류율만이 아니라 지연 시간을 지켜보세요. Cloudflare는 거부하지 않고 속도를 늦추므로, p99 지연 시간 상승이 IP 한도를 넘었다는 첫 신호입니다. 오류로 나타나기 훨씬 전입니다.
• 헤더를 추적하세요. Poly-RateLimit-Remaining은 읽는 데 비용이 들지 않으며 남은 예산을 정확히 알려줍니다.

요청 한도는 데이터 접근과 같지 않습니다

마지막으로 분명히 해 둘 것이 있습니다. 저희가 가장 자주 보는 오해이기 때문입니다. 어떤 요청 한도 등급도 과거 오더북 깊이를 제공하지 않습니다. Polymarket API는 오더북의 현재 상태를 제공합니다. 지난 화요일 14:03:17에 오더북이 어땠는지에 대한 과거 아카이브는 노출하지 않으며, 마켓 결과가 확정되면 오더북은 404를 반환합니다.

이는 속도 제한 문제가 아니라 구조적 공백이며, 어떤 백오프 로직으로도 해결되지 않습니다. 전략을 백테스트하려면 누군가 당시에 기록해 둔 특정 시점 스냅샷이 필요합니다. 바로 그것을 제공하기 위해 PolyTest가 존재합니다. 전체 오더북 깊이, 1초 미만 해상도, 누락 없는 Polymarket 암호화폐 Up/Down 마켓의 과거 스냅샷 240M+개.