Banata

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 needed

Over this:

text
prompt -> repeated client polling -> repeated message reads

Handling 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