Rate limits
| Endpoint | Limit |
|---|---|
POST /parts | 30 part creations per minute, per team |
POST /parts/{partId}/programs | 30 program creations per minute, per team |
Each limit is per team and shared across all of a team's API keys: every key on a
team draws from the same budget. The two limits are tracked in separate budgets,
so program creations do not consume the part-creation quota, and vice versa. Other
endpoints (including the GET reads) are not subject to these per-team quotas.
How the pacing works
Each 30-per-minute budget is enforced as a steady pace of one request every
2 seconds, not a burst of 30 at the top of each minute. Each accepted request
reserves the next slot 2 seconds later. Send again before that slot opens and you
get a 429 Too Many Requests whose Retry-After header tells you exactly how
many seconds to wait. Idle time doesn't bank a burst, so after a quiet stretch you
still get one slot every 2 seconds rather than 30 at once.
Honor the Retry-After value before retrying, and pair retries with
idempotency keys so a retry can't create a duplicate part.
Creating parts or programs faster does not make them finish faster. Each part
and program runs asynchronous Engine processing after it is created, so creating
the full 30 a minute can slow how quickly each one returns a complete (ready)
response, as the Engine works through them in turn. If you need results sooner,
create at a steadier pace and poll for status.