Skip to main content
The /v1 API enforces two independent request budgets. A request is refused if either budget is exhausted. The per-key budget follows the key wherever it is used. The per-IP budget is the only budget for unauthenticated traffic and a second ceiling for authenticated traffic.
Limits are enforced before authentication, so requests with invalid or missing credentials also count against the source budget. Exact numeric budgets are operator-configured and may change; the response contract below is the stable interface to build against.
Authenticate with either Basic credential shape — see Quickstart (apikey:secret or secret:). Set BASE to the organization’s regional host — see Regions.

The 429 response

When a budget is exhausted, the API returns 429 Too Many Requests with a Retry-After header (in seconds) and the standard problem-details body:
429 Too Many Requests
The response does not say which budget was exhausted. Treat every 429 the same way: wait, then retry.

Handling 429s

1

Honor Retry-After

Wait at least the number of seconds in the Retry-After header before retrying. Retrying earlier only re-consumes budget on requests that will be refused.
2

Back off exponentially on repeats

If a retry is refused again, increase your backoff and add random jitter so parallel workers do not retry in lockstep. Never shorten the server’s Retry-After to fit a local cap. If the server asks you to wait longer than your retry budget allows, stop and schedule the work for later.
3

Smooth your request rate

Prefer a steady request rate over bursts. For bulk reads, use the maximum page size (limit=500) to cover the collection in fewer requests — see pagination. When several list walks run in parallel (for example Power BI tables), keep concurrency modest and honor Retry-After so a temporary 429 does not fail the whole refresh.
This example retries only 429 responses for a GET request, with at most five attempts and at most 60 seconds of waiting between attempts. It stops immediately on other errors. Network timeouts propagate to the caller. Configure timeouts and retry budgets to suit your workload. requests interprets the read timeout as the maximum idle time while receiving data, not an overall deadline. Load LIVING_SECURITY_API_KEY from your secret manager. Install requests before running this example. Call get_with_retry("/organization") to use it.
Python
Do not copy this loop around a write operation. A timeout after a write may mean the server committed it before the connection failed. Repeat a write only when that operation’s reference explicitly documents idempotency, preserving the same key and payload. Otherwise reconcile the resource state before trying again. Size refresh cadence against your key budget and page size. A full historical load of a large collection is a one-time cost; prefer incremental windows for steady-state refreshes so each run stays well under the budget. Always set limit=500 explicitly — the default of 25 multiplies request count.