longrun.
Usage limits and availability

Docs

Essentials / Usage limits and availability

Usage limits and availability

Understand configured limits before submitting work.

1. Action limits

Each action reference lists its applicable file or text size limits, processing deadline, and limits for specific list fields. These are ceilings, not a promise that every file below them will succeed. Content, format and engine availability also matter.

2. Workspace capacity

Check GET /v1/usage for recorded run activity and stored file usage. Its storage_limit_bytes field reports the workspace file storage allowance. Compare it with stored_bytes.value; template design JSON is separate. WORKSPACE_RUN_LIMIT returns HTTP 429 when your workspace has reached its active-run limit. Wait for jobs to finish before retrying.

Inspect your usage
curl --request GET "https://api.uselongrun.app/v1/usage" \
  --header "Authorization: Bearer ${API_KEY}"
Storage fields · illustrative
{
  "stored_bytes": {
    "value": 10485760
  },
  "storage_limit_bytes": 1073741824
}

3. Rate limits

There is no documented universal requests-per-minute API allowance. Account sign-in has separate anti-abuse throttling and may return Retry-After. Respect any Retry-After response and use bounded exponential backoff with jitter; avoid busy polling.

4. Service availability

If a request returns ENGINE_UNAVAILABLE, the requested processing service is currently unavailable. Retry later. If the error persists, contact support with the action name and any run ID.

5. Pagination

File and run lists accept limit (1–200, default 200) and offset (0–1,000,000, default 0). Responses are arrays. Filter before paginating. Concurrent changes can shift offset-based results.

Fetch the first 20 runs
curl --request GET "https://api.uselongrun.app/v1/runs?limit=20&offset=0" \
  --header "Authorization: Bearer ${API_KEY}"