요청 수 제한(Rate Limits)

업비트 API의 요청 수 제한(Rate Limits) 정책 안내 및 구현 가이드입니다.

기본 정책 안내

  • 요청 수 제한은 초(Second) 단위로 적용됩니다.
  • 같은 그룹의 API는 요청 수를 함께 차감합니다. 각 API의 그룹과 정책은 본 문서 하단과 API Reference의 Rate Limit 영역에서 확인할 수 있습니다.
  • 초당 최대 허용 요청 수는 공지 후 변경될 수 있습니다. 서비스 상황에 따라 추가 제한도 발생할 수 있습니다. 잔여 요청 수를 확인하여 과도한 요청을 보내지 않도록 유의해 주세요.
  • Origin 헤더를 포함한 요청에는 별도 정책이 적용됩니다. 시세 조회(Quotation) REST API와 WebSocket 요청은 모두 10초당 1회만 허용됩니다. 자세한 내용은 관련 공지를 확인해 주세요.

측정 단위

측정 단위는 기능 분류에 따라 달라집니다. 시세 조회는 IP, 거래·자산 관리는 포켓 단위로 측정됩니다. WebSocket은 연결 요청과 데이터 요청을 구분해 측정됩니다.

기능 분류 측정 단위 설명
시세 조회 REST API
(Quotation)
IP 한도는 IP 주소 단위로 적용됩니다. 같은 IP의 모든 요청은 하나의 한도를 공유합니다.
거래·자산 관리 REST API
(Exchange)
포켓(Pocket) 한도는 포켓 단위로 적용됩니다. 같은 포켓의 여러 API Key는 하나의 한도를 공유합니다.
WebSocket 연결 요청 IP 또는 포켓 한도는 연결 방식에 따라 다르게 적용됩니다. 인증 없이 연결하면 IP, 인증 정보를 포함해 연결하면 포켓 단위로 측정됩니다.
WebSocket 데이터 요청 커넥션(Connection) 한도는 WebSocket 연결 1개마다 적용됩니다. 연결을 여러 개 맺으면 각 연결이 별도의 한도를 가집니다.

포켓 단위 — 독립 한도와 처리량 확장

거래·자산 관리(Exchange) 요청은 포켓 단위로 차감됩니다. 같은 포켓의 여러 API Key는 하나의 한도를 공유하고, 서로 다른 포켓은 각자 독립된 한도를 가집니다. 포켓별 한도는 서로 간섭하지 않습니다. 따라서 운영 중인 포켓 수만큼 계정 전체의 처리량이 늘어납니다. 예를 들어 메인포켓 1개와 서브포켓 5개가 각각 exchange.default(초당 30회)를 사용하면, 계정 전체로는 초당 최대 180회까지 처리할 수 있습니다. 개별 포켓의 한도는 30회로 동일합니다.

계정 = 메인포켓 1개 + 서브포켓 5개 · 각 포켓이 exchange.default 초당 30회를 독립 보유 → 계정 합산 최대 180 req/s
메인포켓차단됨 · HTTP 429
30 / 30회 사용 — 한도 도달
Key AKey B↳ 같은 포켓의 Key는 한도 공유
서브포켓 1요청 가능
12 / 30회 사용
서브포켓 2요청 가능
6 / 30회 사용
서브포켓 3요청 가능
0 / 30회 사용
서브포켓 4요청 가능
18 / 30회 사용
서브포켓 5요청 가능
3 / 30회 사용

메인포켓이 한도에 도달해 차단되어도 서브포켓 5개는 영향을 받지 않습니다. 각 서브포켓은 자신의 한도만큼 요청할 수 있습니다. 처리량을 늘리려면 API Key가 아니라 포켓을 분리해 발급해야 합니다.


커넥션 단위 — 커넥션별 독립 한도

WebSocket은 한 번 연결을 맺으면 그 연결을 통해 계속 메시지를 주고받습니다. 연결 이후의 데이터 요청은 각 연결마다 따로 한도가 적용됩니다. 따라서 처리량이 부족하면 연결을 나누어 늘릴 수 있습니다.

동일 포켓에서 맺은 3개 커넥션 · 각 커넥션당 초당 5회를 독립 보유
Connection #1차단됨
5 / 5회
Connection #2요청 가능
2 / 5회
Connection #3요청 가능
0 / 5회

Connection #1이 한도(초당 5회 / 분당 100회)에 도달해 차단되어도 #2, #3은 영향을 받지 않습니다. 각 연결은 자신의 한도만큼 요청을 보낼 수 있습니다.


Rate Limit 그룹별 정책

API는 Rate Limit 그룹으로 묶입니다. 같은 그룹의 API는 초당 한도를 함께 차감합니다.

Rate Limit 그룹 정책 적용 단위 대상 API
Quotation
market
초당 최대 10회 IP
  • 페어 목록 조회
  • Quotation
    candle
    초당 최대 10회 IP
  • 초(Second) 캔들 조회
  • 분(Minute) 캔들 조회
  • 일(Day) 캔들 조회
  • 주(Week) 캔들 조회
  • 월(Month) 캔들 조회
  • 연(Year) 캔들 조회
  • Quotation
    trade
    초당 최대 10회 IP
  • 최근 체결 내역 조회
  • Quotation
    ticker
    초당 최대 10회 IP
  • 페어 현재가 조회
  • 마켓 현재가 조회
  • Quotation
    orderbook
    초당 최대 10회 IP
  • 호가 정보 조회
  • 호가 모아보기 단위 정보 조회(Deprecated)
  • Exchange
    default
    (exchange default)
    초당 최대 30회 포켓
  • 포켓 정보 조회
  • 포켓별 API Key 목록 조회
  • 포켓 잔고 조회
  • 서브포켓 잔고 조회
  • 메인포켓 자산 이전 / 이전 목록 조회
  • 서브포켓 자산 이전 / 이전 목록 조회
  • 주문 가능정보 조회
  • 개별 주문 취소
  • 지정 주문 목록 취소
  • 개별 주문 조회
  • id로 주문 목록 조회
  • 체결 대기 주문 조회
  • 종료 주문 조회
  • 디지털 자산 출금하기
  • 원화 출금하기
  • 디지털 자산 출금 취소 접수
  • 출금 가능 정보 조회
  • 출금 허용 주소 목록 조회
  • 개별 출금 조회
  • 출금 목록 조회
  • 입금 주소 생성 요청
  • 개별 입금 주소 조회
  • 입금 주소 목록 조회
  • 입금 가능 통화 조회
  • 개별 입금 조회
  • 입금 목록 조회
  • 원화 입금
  • 트래블룰 지원 거래소 목록 조회
  • 입금 UUID로 트래블룰 검증 요청
    (동일 입금 건에 대해 10분당 최대 1회 요청 허용)
  • 입금 TXID로 트래블룰 검증 요청
    (동일 입금 건에 대해 10분당 최대 1회 요청 허용)
  • 통화별 입출금 서비스 상태 조회
  • API Key 목록 조회
  • Exchange
    order
    초당 최대 8회 포켓
  • 주문 생성
  • 취소 후 재주문
  • Exchange
    order-test
    초당 최대 8회 포켓
  • 주문 생성 테스트
  • Exchange
    order-cancel-all
    2초당 최대 1회 포켓
  • 주문 일괄 취소
  • websocket-connect 초당 최대 5회 인증 미포함: IP
    인증 포함: 포켓
  • WebSocket 연결 요청
  • websocket-message 초당 최대 5회, 분당 100회 커넥션
  • WebSocket 데이터 요청 메시지 전송
  • Rate Limit 그룹별 초당 최대 허용 요청 수는 서비스 정책에 따라 공지 후 변경되거나, 서비스 상황에 따라 추가 제한이 발생할 수 있습니다.


    잔여 요청 수 확인 방법

    REST API 응답의 Remaining-Req 헤더로 잔여 요청 수를 확인할 수 있습니다.

    Remaining-Req: group=default; min=1800; sec=29
    • group — 요청이 속한 Rate Limit 그룹
    • min — (Deprecated) 분 단위 필드. 고정 값이 반환되므로 참조하지 마세요.
    • sec — 현재 잔여 요청 수. 0이면 일정 시간 후에 다시 요청해야 합니다.
    HTTP 상태 의미 권장 조치
    429 Too Many Requests 초당 한도 초과 다음 초 경계까지 대기 후 재시도
    418 I'm a teapot 429 누적으로 일시 차단 (동일 IP·포켓·커넥션 단위) 응답에 포함된 차단 시간 정보를 확인 후, 안내된 시간 이후 재시도

    정책 위반이 반복되면 차단 시간은 점진적으로 증가합니다.


    관련 문서


    ※ This English version is a translation of the original Korean version of the Upbit Developer Center, generated using a third-party tool. In the event of any discrepancies, the Korean version shall take precedence.