요청 한도

주문 작업과 API 요청에 대한 지갑별 요청 한도입니다.

개요

요청 한도는 고정된 60초 윈도우를 사용합니다. 지갑 한도는 해당 지갑의 등급에 따라 정해지며 다음 항목에 적용됩니다.

• 주문 제출 (POST /order, PUT /order, WebSocket PlaceOrder, TEE 경로 퍼프 주문 제출)
• 주문 취소 (DELETE /order, DELETE /order_cloid, TEE 경로 퍼프 취소)
• API 요청 (지갑 단위 조회 및 기타 서명된 쓰기 요청)

취소, 에이전트 승인, MMP 쓰기, 공개 리스크 시뮬레이션에는 네트워크 소스별로 구분되는 별도 한도와 프로세스 전체 상한이 적용됩니다.

카운터는 각 API 프로세스의 메모리에 보관됩니다. 레플리카 간에 공유되지 않으므로, 공개된 수치는 클러스터 전체 예산이 아니라 단일 프로세스가 허용하는 최대치로 보아야 합니다.

기본 한도

등급	주문/분	취소/분	API 요청/분	최대 미체결 주문	최대 포지션
기본	60	120	600	100	50
Tier 1	30	60	300	50	20
Tier 2	120	300	1,200	500	200
마켓메이커	1,200	2,400	6,000	5,000	무제한

신규 지갑에는 기본 한도가 적용됩니다. 등급 상향은 고객지원에 문의하시기 바랍니다. 현재 API 요청 한도는 GET /orders?wallet=...와 같은 지갑 단위 조회 응답의 X-RateLimit-Limit 헤더에서 확인할 수 있습니다.

요청 한도 초과 응답

요청 한도를 초과하면 API는 429 Too Many Requests를 반환합니다.

{
  "error": "rate_limit_exceeded",
  "message": "Rate limit exceeded for OrderPlacement: 60 per minute, retry after 45 seconds",
  "retry_after_secs": 45,
  "limit": 60
}

응답 헤더

지갑 한도가 적용되는 엔드포인트는 다음 헤더를 반환합니다. 429 응답에는 X-RateLimit-Limit, X-RateLimit-Remaining: 0, Retry-After가 포함되지만 X-RateLimit-Reset은 포함되지 않습니다.

헤더	설명	예시
X-RateLimit-Limit	윈도우당 허용되는 최대 요청 수	60
X-RateLimit-Remaining	현재 윈도우에서 남은 요청 수	42
X-RateLimit-Reset	윈도우가 초기화되는 시점의 Unix 타임스탬프(초 단위, 성공 응답에만 포함)	1737312060
Retry-After	재시도까지 남은 초(429 응답에만 포함)	45

응답 헤더 예시

성공한 요청:

HTTP/1.1 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1737312060

한도에 걸린 요청:

HTTP/1.1 429 Too Many Requests
Retry-After: 45
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0

요청 한도 카테고리

요청 한도는 작업 유형별로 따로 집계됩니다.

주문 제출

지갑별로 등급의 주문/분 한도에 대해 집계됩니다.

• POST /order 및 PUT /order
• WebSocket PlaceOrder
• POST /v1/tee-perp/orders/submit 및 기타 퍼프 주문 제출(Account 매니저 기준으로 집계)

POST /bulk_order와 PUT /bulk_order는 요청당 최대 50건으로 제한됩니다.

주문 취소

지갑별로 등급의 취소/분 한도에 대해 집계됩니다.

• DELETE /order 및 DELETE /order_cloid
• 퍼프 취소(서명한 API 지갑 기준으로 집계)

DELETE /bulk_order와 DELETE /bulk_order_cloid를 포함한 모든 취소 경로는 서명 검증 전에 분당 네트워크 소스별 6,000건, 프로세스 전체 60,000건의 취소 레그로도 제한됩니다. 일괄 취소는 항목당 1레그로 집계됩니다.

API 요청

지갑별로 등급의 API 요청/분 한도에 대해 집계됩니다.

• 지갑 단위 조회(wallet 쿼리 파라미터 기준)
• 위에 나열되지 않은 서명된 쓰기 요청(예: MMP 설정, 증거금 모드)

RFQ 제출

POST /rfq/request 및 WebSocket RFQ 제출 명령은 등급과 관계없이 지갑당 분당 10건으로 제한됩니다.

리스크 시뮬레이션

공개 포트폴리오 및 주문 시뮬레이션(POST /risk/simulate/portfolio, POST /risk/simulate/orders, 퍼프 미리보기 POST /v1/tee-perp/preview)에는 분당 네트워크 소스별 60건, 프로세스 전체 600건의 별도 한도가 적용됩니다. 하나의 API 프로세스에서 동시에 실행되는 시뮬레이션은 최대 4개입니다. 할당량을 초과하거나 시뮬레이션 워커가 포화 상태인 요청은 429 Too Many Requests를 반환합니다.

에이전트 승인

POST /approve-agent, DELETE /revoke-agent, DELETE /revoke-all-agents는 서명 검증 전에 분당 네트워크 소스별 120건, 프로세스 전체 1,200건으로 제한됩니다.

MMP 쓰기

MMP 설정 쓰기는 지갑의 API 요청 한도와 별도로, 서명 검증 전에 분당 네트워크 소스별 120건, 프로세스 전체 1,200건으로 제한됩니다.

포지션 및 주문 한도

요청 한도 외에도 지갑에는 최대 미체결 주문 수와 포지션 수 한도가 있습니다.

한도 유형	설명	거부 조건
최대 미체결 주문	동시에 유지할 수 있는 최대 미체결 주문 수	지갑이 한도에 도달한 상태에서는 신규 주문 거부
최대 포지션	고유 포지션의 최대 개수(-1 = 무제한)	새 포지션을 여는 주문은 거부

이는 HTTP 오류가 아니라 주문 거부입니다. 주문 응답은 HTTP 200이며 status: "REJECTED"와 다음과 같은 reason을 포함합니다.

max_open_orders_exceeded: current=100, limit=100
max_positions_exceeded: wallet 0x... has 50 positions, limit is 50

권장 사항

요청 한도 처리

1. 헤더 모니터링: X-RateLimit-Remaining을 사전에 추적합니다
2. Retry-After 준수: 재시도 전에 지정된 시간만큼 대기합니다
3. 백오프 구현: 429가 반복되면 지수 백오프를 사용합니다

import time

def place_order_with_retry(order, max_retries=3):
    for attempt in range(max_retries):
        response = api.place_order(order)

        if response.status_code == 429:
            retry_after = int(response.headers.get('Retry-After', 60))
            time.sleep(retry_after)
            continue

        return response

    raise RateLimitError("Max retries exceeded")

요청 사용 최적화

1. 일괄 엔드포인트 사용: 여러 주문은 POST /bulk_order로 한 번에 요청합니다
2. 취소 일괄 처리: 여러 번의 DELETE /order 요청 대신 DELETE /bulk_order 또는 DELETE /bulk_order_cloid를 사용합니다
3. 업데이트는 WebSocket으로: GET /orders를 폴링하는 대신 주문 업데이트를 구독합니다

모니터링

클라이언트 측에서 다음 지표를 추적하십시오.

• 작업 유형별 요청 속도
• X-RateLimit-Remaining 추이
• 429 응답 빈도
• 평균 Retry-After 대기 시간

오류 참조

HTTP 상태	오류 코드	설명
429	rate_limit_exceeded	요청 한도 초과, 지정된 시간 후 재시도

전체 오류 목록은 오류를 참고하십시오.