Rate limits

Limits are enforced per credential (per API key) over a sliding window, across all three interfaces — REST, MCP, and A2A draw from the same buckets.

Bucket	Applies to	Limit
Global	every request	1,000 / hour
Reads	GET/list/status endpoints	5,000 / hour
App creation	POST /v1/apps, exepad_create_app	10 / hour
AI edits	POST /v1/apps/{id}/edits, exepad_modify_app, A2A message/send	30 / hour
File uploads	POST /v1/apps/{id}/files	50 / hour
Deploys	publish / preview / unpublish / rollback	30 / hour

Headers

Every response reports the tightest bucket it consumed:

x-ratelimit-limit: 1000
x-ratelimit-remaining: 992
x-ratelimit-reset: 1784142600
x-request-id: 3af9974a-…

Handling 429

A throttled request returns 429 with a Retry-After header and the standard error envelope. Back off until Retry-After (or x-ratelimit-reset) and retry — with jitter if you run concurrent workers.

Design around the expensive buckets

Creation and edit limits exist because each call triggers a multi-minute AI build. Poll edit status via the read bucket (5,000/h), or replace polling entirely with webhooks — edit.completed / app.deployed cost you nothing.

Abuse protection

Independent of per-key limits, the api. / mcp. / a2a.exepad.com edge applies IP-level rate limiting, and accounts have a publish-velocity cap on *.exepad.app (anti-farming). Sustained abuse can disable a key.