Platform
Rate Limits
Understand how to stay well within Banata rate limits by designing for async workflows, fewer status reads, and cleaner task completion handling.
Rate limits protect the platform and keep integrations predictable.
The best way to stay within them is not just “retry less”.
It is to design your workflow around the right API pattern.
Design for fewer requests
The easiest way to stay comfortably inside limits is:
- use
launch()instead of repeated create/get loops - use
promptAsync()instead of long synchronous waiting - use webhooks instead of constant polling
- reuse one sandbox for one meaningful multi-step job instead of creating many tiny ones
High-frequency request families
The request families most likely to grow quickly are:
- sandbox lifecycle reads
- execution requests
- file operations
- agent prompts
- task status checks
Best practice
Prefer this:
text
promptAsync -> webhook -> getAgentTask once if neededOver this:
text
prompt -> repeated client polling -> repeated message readsHandling 429
If you receive 429:
- back off
- retry after a delay
- avoid immediate loops
The most important fix is usually architectural:
- fewer repeated reads
- more webhook-driven completion