SpinupSpinup Docs
Runtime API

Rate Limits

Understand Spinup API rate limits, 429 responses, and Retry-After handling.

Spinup applies shared rate limits to protect the public API, control-plane API, and the path that handles runs. Limits may vary by plan, trust posture, and operational abuse response, so clients should not hard-code exact quotas.

When a request is rate limited, the API returns 429 Too Many Requests.

HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: application/json
{
  "defined": false,
  "code": "TOO_MANY_REQUESTS",
  "status": 429,
  "message": "Too many requests. Please wait a moment and try again."
}

If the response includes Retry-After, wait at least that many seconds before retrying. Use exponential backoff with jitter when Retry-After is absent.

Runtime runs

POST /v1/agents/{agentId}/exec is the most expensive public API path. It is limited across several dimensions, including API key, agent, workspace, and source network. Spinup also limits concurrent runs per agent and workspace.

Today, design clients as if one agent runs one prompt at a time. If you need parallel work, create separate agents or queue requests client-side.

Control-plane writes

Workspace and agent management writes can also return 429, including agent creation, API key issuance, and other sensitive mutation paths. Treat these as backpressure signals and retry only after the suggested wait.

Client guidance

  • Honor Retry-After when present.
  • Avoid tight polling loops.
  • Keep /exec timeouts only as long as needed.
  • Do not immediately retry failed writes in parallel.
  • Surface a clear user-facing message when a human action is being throttled.