Rate Limits

Rate limits are applied per account and counted in two independent buckets. A request only consumes the bucket for its own kind, so heavy polling never eats into the allowance for creating tasks.

Bucket	Default limit	Endpoints
Write (operations)	20 requests / 10 seconds	POST /v1/tasks, POST /v1/storages/promote, POST /v1/storages/delete
Read (queries)	60 requests / 10 seconds	GET /v1/tasks, GET /v1/tasks/:id, GET /v1/storages

• Both buckets use a sliding 10-second window and are counted per user, not per API key — several keys under the same account share one allowance.
• Polling with GET /v1/tasks/:id counts only against the read bucket. It never consumes write allowance, so a normal polling loop will not block task creation.
• Every request that reaches the endpoint is counted, including requests that are then rejected with a 4xx (for example a malformed body). Retrying a failed submit still uses write allowance.
• Requests rejected before the limit check — for example a missing or invalid API key (401) — are not counted.
• Beyond the request rate, the platform typically supports 100+ concurrently running tasks.

Request rate is not a concurrency cap

Rate limits control how quickly new tasks are submitted, not how many tasks are queued or running. Tasks already queued or running do not consume the allowance in later time windows; actual execution speed still depends on the selected model and service capacity.

When the limit is exceeded

When a bucket runs out:

• The request is rejected with HTTP 429
• The response includes Retry-After, set to the length of the rate-limit window in seconds
• The response error code is RATE_LIMITED
• The rejected request does not enter the task queue

HTTP/1.1 429 Too Many Requests
Retry-After: <seconds>
Content-Type: application/json

{"code":429,"message":"too many requests, retry later","data":null,"error_code":"RATE_LIMITED"}

Responses do not carry X-RateLimit-* headers, so there is no remaining-quota signal to read ahead of time. Retry-After is only present on a 429.

Wait for the Retry-After interval before retrying, and use exponential backoff with jitter to avoid synchronized retries.

Requesting a higher limit

If you continue to receive HTTP 429 responses, contact HiAPI support to request a higher account request limit. Requests are evaluated based on the intended workload, request pattern, and account requirements.