DEVELOPER PREVIEW · VERIFIED SEPTEMBER 27, 2026

Rate limits

Budget requests across your whole game, not just one player. Several limits apply together; a request can be throttled by any one of them.

Build a quiet client

Use one request queue per session, avoid overlapping refreshes, and save when something changes. Read the visitor inbox on focus or before a session; use bounded polling only when your game needs it. Every separate visitor/shared-data fetch also costs a request.

When the API returns 429, pause the queue for at least Retry-After seconds, then add a little random delay. Do not disconnect the player or erase their save because of throttling.

Current platform budgets

Shared by	Limit	What it includes
One player in one project	60 requests / minute	Game reads and writes; successful token issuance also uses this budget.
One player in one project	20 writes / minute	State, capsule, showcase, shared-data and other non-read game operations; successful token issuance.
All players of one project	10 requests / second	Project-associated gameplay, connection and token requests. First-party delivery also uses the project budget.
All players of one project	60,000 / day by default	Your actual `daily_request_limit` appears in the developer console and may differ.
All projects of one developer	180,000 / day	Combined project traffic. Increasing a project's daily allowance does not change this ceiling.
One public IP address	600 / minute	Platform traffic across devices and projects, including authorization polling. Shared networks share this budget.
One player in one project	512 token issuances / day	Authorization, refresh and device-token issuance. Keep the session rather than reconnecting for every request.

These database windows are fixed, aligned to Unix time; daily windows reset at midnight UTC. Rejected attempts can consume earlier checks, so hammering an exhausted limit can exhaust another one. API calls are not a count of unique people or bumps. Listing visitors does not call the app's profile resolver once per visitor.

The console shows your daily project allowance. It does not currently expose remaining counters for every limit. Use the response's Retry-After; do not infer remaining capacity from a single successful request.

Connection, polling and concurrency limits

Device-authorization starts: 20 per minute per project.
/oauth/pending status calls: 30 per minute per request reference or user code. QR reads: 30 per minute per reference/code in a separate bucket.
Device token polling must follow the returned interval (initially five seconds). slow_down adds five seconds to the polling interval. Pending device-token polls also use the project budget.
Admission control allows at most four concurrent platform requests per token/installation identity, sixteen per IP and thirty-two across the platform process. It can return 429 before any durable quota is reached.
Additional in-memory burst controls reject floods and repeated invalid requests. These are protective ceilings, not reserved throughput.

Plan for all active players

One inbox fetch plus three shared-document fetches every ten seconds is 24 requests per minute per player, before saves or sign-in. Thirty players doing that average 12 requests per second, exceeding the shared project limit. Simultaneous polls can hit the limit even with fewer players.

For a race that lasts several minutes, fetch the roster before the race instead of throughout it. Deduplicate by visitor_id, avoid overlapping refreshes, and briefly cache an unavailable shared-document result for that reference. Revalidate personal data before reuse; caching must never bypass expiry, withdrawal or access checks.

The Racing Demo uses a ten-second lobby refresh, one refresh in flight, 300 ms request spacing, a 45-call rolling minute budget and bounded backoff. That leaves per-player headroom but does not guarantee capacity for a busy project. Use longer refresh intervals when instant updates are unnecessary.

Before a public launch or a busy event, estimate active players × calls per session and request a capacity review. Increasing the daily project quota alone does not remove its per-second, developer-wide or shared-IP limits.

Request higher limits

Open your project in the developer console and expand Request higher limits. Enter the capacity you need (with units), expected concurrent players and peak traffic, your request-handling approach, and timing. The console prepares an email with your public project ID and current daily allowance. Send it to support@webump.app from your developer account email. You can copy the draft if you do not use a desktop email app.

This is an email review, not an automatic quota change or a tracked console submission. Keep tokens, installation secrets and player data out of the request. Daily allowances can be adjusted individually; burst or other shared limits require a separate capacity review and may require backend changes.

How we review an increase

We consider observed usage, expected audience, efficient polling and caching, retry handling, and available server capacity. Start with a measured increase and review its impact. Per-player limits and abuse controls still apply.

Open-source and closed-source games use the same authorization boundary: public client configuration is not a credential. Browsers and downloadable apps cannot reliably conceal reusable secrets. A valid player token can be used outside the official game, within its permissions and limits. Copying the configuration alone does not grant player access, and a larger project budget never grants access to more player data. Keeping source private is not a qualification for higher limits.

Handle throttling without losing progress

Read Retry-After as seconds and apply the wait to the whole session queue. Add jitter after that minimum; cap the number of retries.
Keep a pending save locally and show a temporary “Sync waiting” state. A 429 is not a sign-out or data-deletion instruction.
Retry a write only when rejection is definite. After an uncertain timeout, re-read state and its ETag before deciding what to write; never blindly replay a consumed authorization code or rotating refresh token.
Handle 409 revision_conflict by reading and merging. Handle 413 quota_exceeded by reducing the document; it is a storage/body limit, not a timer.
Treat shared-data 410 as unavailable for that reference, not a rate-limit error. Drop inaccessible personal data; an authorized basic card may still be usable.

HTTP/1.1 429 Too Many Requests
Retry-After: 12
Content-Type: application/json

{"error":"rate_limited"}

The wait can be much longer for a daily budget. Retry-After is exposed to browser clients through CORS. Keep the app responsive while waiting; don't block the UI thread.

Does weBump limit people to eight bumps a day?

No. The first-party app currently allows 300 profile-resolution requests per installation per hour. That counts resolver calls, including retries, not a daily allowance of eight people. Bumps are recorded locally; throttled resolutions remain pending for retry within the rolling-ID validity window.

These first-party limits are separate from your game's platform budgets. Developers cannot use first-party routes with game tokens. The app's rolling-ID request obtains a full 24-hour batch of 15-minute IDs; it is not one request per person encountered.

Integration tutorial → · Interactive API reference →