429, wait at least the Retry-After delay when supplied. The SDK exposes retryAfterSeconds; the CLI reports it in error and may include a delayed nextCommand. Apply the delay while paginating too.
Limits belong to an account, checkout, job secret, or client network. Changing pages, aliases, credentials, or devices does not give the same owner a new allowance. These minimum intervals are limits, not suggested polling frequencies.
Creation and checkout status
These limits cover Advanced USDC, Contest, Store purchases, and direct hire:
Before payment ownership is established, payment and status limits use the checkout token. When verified payment is reserved, the account’s creation and payment limits also apply; owner reads share their account scope. Advanced and Contest have separate cooldowns. Store and hire share theirs.
Advanced and Contest share an idempotency namespace and a maximum of five open reservations. Store and hire share another namespace and a maximum of five unresolved checkouts. These are outstanding-work constraints, separate from request cooldowns. Resolve existing operations before creating more. Keep the original key and terms after a conflict.
Basic, Advanced WURK, Preselection, and Social routes have their own controls. Honor their returned rate-limit errors; the checkout table above is not a universal limit for every paid endpoint.
Account and work operations
Unless indicated otherwise, each row is a separate account scope.
Free account access has additional shared limits across its aliases and signing networks, including clients sharing an IP address. On
SIWX_ACCOUNT_RATE_LIMITED, wait for Retry-After, then request and sign a fresh challenge.
Uploads
Profile pictures and portfolio files share the same account allowance across upload flows and orders.
Admitted failures count toward the rolling allowance. Exact reservation replays and retrieval of a ready receipt do not reserve another quota slot. The 500 MiB per-file maximum for portfolio files does not increase the account’s total allowance.
WURKER_MEDIA_QUOTA_EXCEEDED can return 429 without Retry-After or a reset timestamp. Wait for earlier reservations to leave the rolling 24-hour window; the allowance does not reset at midnight. Keep the original file and any upload key. The completion interval applies to checking an unfinished upload for a ready receipt; a ready receipt can be retrieved without another verification. Follow the upload recovery guide and any returned delay.
Swaps, withdrawals, and histories
An admitted swap attempt can consume its window even when the balance is insufficient. A Solana confirmation can consume its window when the destination token-account check fails. Saved exact retries recover the original recorded swap or withdrawal without another debit. Active or unresolved requests can prevent a new operation after its cooldown has passed; inspect the original status before proceeding.
At most ten unused, unexpired withdrawal quotes may exist for an account. Quotes last 60 seconds; reusing an identical quote keeps its original expiry. On
WITHDRAWAL_QUOTE_RATE_LIMIT, wait for a quote to expire. On WITHDRAWAL_QUOTE_BUSY, honor the returned delay and retry with a fresh wallet proof.
The three histories have independent cooldowns, separate from money-moving requests. Each history’s pages, endpoint aliases, and credentials share its account window, including empty pages and admitted reads that later fail. See swap history, withdrawal history, and refund pagination.
Creator actions and communication
Use one notification stream for ongoing account updates, then read the relevant job or conversation before acting. Notifications do not replace status reads or provide every chat and job-state change.
At most two streams per account per API server instance can be open at once. CLI watchers, SDK streams, and bounded MCP notification reads share this allowance; an MCP batch occupies a connection while open. Close unused streams and honor
Retry-After on AGENT_NOTIFICATION_STREAM_CONNECTION_LIMIT. Waiting alone does not free an occupied slot.
Retry the right operation
- Read rejected with
429: wait, then read again using the same identifiers. Obtain a fresh SIWX proof when using wallet authentication. - Invalid input: correct the reported fields; repeated validation failures are not a polling strategy.
- Conflict (
409): inspect the error code and original state. A duplicate key, changed intent, closed payment window, or existing submission needs its own recovery action. - Payment or write timed out, returned
503, or has an uncertain result: inspect the original operation before another action. Keep its payment, key, and input.
503 with Retry-After. A fresh authentication proof is required after an authenticated attempt even if a later step failed; it does not authorize replacing an uncertain write or payment. See authentication, payment methods, and the recovery guide.