한도는 무엇이며, 거부는 어떤 모습입니까?

REST API · 하나의 요청 한도, 유형화된 타임아웃, 사용 중인 슬롯, 수정 방법이 담긴 입력 오류

  • 에이전트용
  • 6분
  • 고급
  • 개발자
  • 호출 간격 조절

ACHIVX Academy 원문 (영어) ↗

분당 1,200 요청의 토큰 버킷 요청 한도 하나(에이전트 카드의 rateLimits. 스킬은 같은 것을 초당 20, 버스트 40으로 표현합니다). 마감 시간을 넘긴 조회는 REST에서 error.code: timeout과 Retry-After: 5가 붙은 503, A2A에서 data.retryable이 붙은 -32050, MCP에서 timeout을 지정하는 도구 오류로 답합니다. MCP의 무거운 도구는 busy로 답할 수도 있습니다. 형식이 잘못된 입력은 코드와 메시지 안의 수정 방법이 붙은 400입니다. 모든 응답에는 X-Request-Id가 붙습니다.

한도

하나의 토큰 버킷 요청 한도(분당 1200 요청, 에이전트 카드의 rateLimits에 공개) — 요청에 대한 한도이지, 무거운 조회가 마감 시간 안에 들어온다는 약속이 아닙니다. SKILL.md 파일은 이를 초 단위로 밝힙니다: IP당 초당 20 요청(버스트 40). MCP 호출에는 같은 속도의 별도 예산이 있어 REST와 분리됩니다: MCP를 쓰는 에이전트와 /v1을 쓰는 스크립트는 서로를 느리게 하지 않습니다. 429는 rate_limited입니다: Retry-After에 따라 간격을 두십시오 — 쉬지 않고 반복하지 마십시오. 모든 조회는 요청 마감 시간 아래에서도 실행됩니다: 그 안에 끝낼 수 없는 조회는 유형화된 타임아웃으로 거부되며, 예산에 도달한 탐색은 완전한 척하지 않고 멈춘 뒤 응답에서 그렇다고 밝힙니다.

접근 경로별 타임아웃

요청 마감 시간 안에 끝나지 않은 조회는 REST에서 error.code: "timeout"과 Retry-After: 5가 붙은 503(메시지는 경로를 지정하고 재시도하면 성공할 수 있다고 말합니다), A2A에서 data: {"reason": "timeout", "retryable": true, "read": "<skill>"}가 붙은 -32050 "deadline exceeded"(스킬 메서드와 SendMessage 모두), MCP에서 도구 오류 timeout: the read did not finish within the deadline; retrying may succeed로 답합니다. 간격을 둔 뒤 재시도하십시오 — 무거운 조회는 다시 시간 초과될 수 있으므로 반복하지 마십시오. 타임아웃은 상태가 아니라 error.code로 구별하십시오: 2026-09-24까지는 504였고, 503은 snapshot_pending과 not_ready에도 쓰입니다. 본문이 이 JSON이 아니고 request_id가 없는 5xx는 엣지에서 온 것입니다: 대상에 대해 아무것도 말하지 않습니다 — 간격을 두고 재시도하되, 결코 빈 응답으로 읽지 마십시오. 시간 초과된 쓰기는 Retry-After 없이 503으로 답합니다: 반복하기 전에 그 효과를 확인하십시오.

MCP의 busy

무거운 도구 여섯 개 — get_address_risk, get_address_exposure, get_address_compliance, get_address_approvals, get_wallet_graph_walk, get_recent_transactions — 는 서버당 고정된 수의 슬롯을 공유합니다. 잠시 안에 빈 슬롯을 찾지 못한 호출은 아무것도 읽지 않고 busy: too many concurrent reads on this server; retry shortly로 답합니다. 형식이 잘못된 입력은 호출이 슬롯을 기다리기 전에 거부됩니다.

입력

형식이 잘못된 매개변수는 메시지에 수정 방법이 담긴 유형화된 오류로 답합니다 — REST에서는 코드(invalid_chain, invalid_address, invalid_limit, unknown_param, …)가 붙은 400, A2A에서는 -32602(예: Invalid params: address required), MCP에서는 문제를 지정하는 도구 오류 — 고쳐서 다시 보내십시오. 2026-10-13 ?chain=0x1은 허용 형식 — id, 문자열로 쓴 id, 슬러그, CAIP-2 id — 을 메시지에 지정하며 invalid_chain으로 답했습니다. 네 개의 경로가 알 수 없는 쿼리 매개변수를 400 unknown_param으로 거부합니다 — /v1/transfers, /v1/verify, /v1/freezes/proposals, /v1/freezes/acts. 그 밖의 모든 곳에서는 알 수 없는 매개변수가 무시되므로, 필터는 매뉴얼에 적힌 그대로 정확히 쓰십시오.

요청 id와 가동 여부

모든 REST, A2A, MCP 응답에는 X-Request-Id가 붙습니다(직접 보내면 그대로 되돌려 줍니다). 응답을 보고할 때 이를 인용하십시오. 매뉴얼 §6이 나열하는 엣지 캐시 조회 — GET /v1/transfers, GET /v1/addresses/…, GET /v1/subscriptions, /v1/networks, /v1/tokens, /v1/methodology, 카드, /.well-known/jwks.json, robots.txt, llms.txt, llms-full.txt, 사이트맵, 두 개의 /a2a-ext/… 명세, 정확한 경로 기준이며 /v1/tokens/{…}는 해당하지 않음 — 에서 id는 응답의 Cloudflare ray <16 hex>-<colo>이며, 보낸 id는 되돌려 주지 않습니다. 그 옆에 cf-cache-status를 인용하십시오. /health와 /ready는 프로세스 가동 여부입니다: 둘 다 200으로 답하는 동안에도 네트워크는 몇 시간 뒤처져 있을 수 있습니다 — 최신성은 /v1/sync/status?chain=입니다. 세 접근 경로가 답할 수 있는 모든 상태와 코드, 그리고 각각의 메시지는 응답은 어떤 것일 수 있습니까?에 나열되어 있습니다. /v1/stats/slo는 서비스 자체의 지연 시간 예산(note에 따르면 API 프로세스별)과 최신성 기준점(ofac_sanctions는 일일·전역, graph_batch는 주간·예산 8일·체인별)이며, 네트워크의 인덱싱 지연이 아닙니다.

Stablecoin scanner ACHIVX에서

에이전트 카드 열기 ↗

출처

더 알아보기

REST API · 호출 간격 조절 · 2026-10-13 작성, 스캐너 자체의 기계용 문서와 그날 조회한 실시간 응답을 바탕으로 했습니다. 구조는 그대로 인용했으며, 수치는 날짜 기준이고 인덱스에 따라 바뀝니다.

이 페이지는 ACHIVX Academy 영어 원문을 한국어로 옮긴 것입니다. 번역과 원문이 다르면 영어 원문이 기준입니다.