요청 제한

보낼 수 있는 요청의 양, 넘었을 때 일어나는 일, 그 밖에 알아 둘 제한.

제한은 서비스를 함께 쓰는 모두를 보호하기 위한 것입니다. 기본값은 일반적인 사용에 넉넉하며, 제한에 걸리면 응답이 얼마나 기다려야 하는지 정확히 알려 줍니다.

한눈에 보기

제한	기본값	걸렸을 때
계정당 쓰기(`createTask`, `retry`, 업로드 …)	10초에 1,000회	`Retry-After`가 붙은 `429`
계정당 읽기(`recordInfo`, `models`, `jobs`, `quote` …)	10초에 1,000회	`Retry-After`가 붙은 `429`
업로드 티켓	10초에 1,000회, 쓰기와 별도로 추가	`Retry-After`가 붙은 `429`
사용량 보고서(`/api/v1/usage`)	계정당 분당 30회	`Retry-After`가 붙은 `429`
에셋 라이브러리	분당 읽기 60회·저장 30회, 하루 신규 에셋 수 제한	`Retry-After`가 붙은 `429`
키 확인 전의 모든 요청	네트워크당 분당 6,000회	`429`
요청 본문	JSON 2 MiB까지	`413`
잔액	계정에 있는 만큼	`40201`
키 지출 한도	정하지 않으면 없음	`40202`

제한은 키가 아니라 계정 단위로 셉니다. 키를 더 만들어도 한도는 늘지 않습니다.

헤더	의미
`X-RateLimit-Limit`	현재 구간의 허용량
`X-RateLimit-Remaining`	구간에 남은 요청 수. 성공한 응답에도 오므로 미리 속도를 늦출 수 있습니다
`Retry-After`	`429`일 때 다시 시도하기 전까지 기다릴 초

위 숫자는 기본값이며 바뀔 수 있습니다. 코드에 박아 두지 말고 헤더를 믿으세요.

{ "code": 429, "msg": "Too many requests. Retry in a moment", "request_id": "req_…" }

한도를 넘은 요청은 대기열에 들어가지 않고 바로 거부되며 비용도 들지 않습니다.

요청 제한은 요청을 보내는 속도를 제한할 뿐, 동시에 실행되는 작업 수를 제한하지 않습니다. 많은 작업을 함께 돌릴 수 있고, 긴 영상은 그저 오래 걸릴 뿐입니다. 수천 개의 작업을 시작해야 한다면 나눠서 보내고 결과는 웹훅으로 받으세요.

출시 행사나 대량 작업으로 더 높은 한도가 필요하면 예상 사용량과 함께 문의해 주세요.