NQD API limits and retries
Understand request allowances, plan limits, and when a retry is safe.
API requests use Core’s finite external allowance and rate groups. No caller header can choose the dashboard channel, unlimited allowance, role, or plan. Credentials and current scope are resolved before the operation’s guarded admission and transaction.
Rate and request-allowance denials return 429 with Retry-After. Financial record and invitation seat limits return 403 plan_limit. Those outcomes are distinct from current permission denial. Nested client directories consume admission for the parent guard and directory. Batch mutations retain the named Core operation’s existing transaction semantics.
No generic Idempotency-Key contract is implemented. A lost response can mean a write committed. Read the source and its effective transaction summary before retrying a financial command. Some payment posts support an existing authored transaction ID and report repeated; that capability does not make every POST safe to retry. Transaction updates and deletes are explicit mutations on the addressed transaction, so retry them only after checking whether the first request committed.
Server clients without Origin are supported. Browser API access permits only configured HTTPS origins and the declared headers; it does not allow credentialed cookies. CORS is not permission. Preflight executes no business operation. Every actual request authenticates normally.
Live traffic, provider cutover, deployment, durable generic retry deduplication, and new scheduling or storage services are outside the current API contract.