Skip to main content
Nubo applies per-user rate limits to prevent runaway scripts from swamping the API. Normal dashboard use never hits them. Scripted clients should just handle 429 gracefully.

​
What’s limited

Write calls (create, update, delete, rollback) are limited. Read calls (GET) are not. You can poll your deployments or your Frame status as often as you like. Limits are per-user and per-endpoint: each write endpoint has its own 60-second bucket, keyed on your account (not on the token you use). So hitting the limit on one endpoint doesn’t block writes to others. Writes are limited conservatively; the exact thresholds are tuned over time based on usage patterns and aren’t part of our stability contract.

​
If you hit the limit

You’ll get back: 
{
  "error": {
    "internal_code": "Q-9pRt2M",
    "message": "too many requests; limit 20 per 60s"
  }
}
Wait up to 60 seconds and retry, and you’ll be back in business.

​
Handling rate limits in your client

A well-behaved client:
  • Backs off on 429 with a short exponential delay (e.g. 2s, 4s, 8s, capped at 60s).
  • Remembers the limit is per-user: all of your tokens count toward the same bucket, so spreading work across multiple Personal Access Tokens won’t raise your effective limit. Consolidating workers behind one client just avoids redundant retries.
  • Logs the internal_code so rate-limit rejections are easy to tell apart from other failures.