Developer documentation
Rate-limit policy for BLERBZ API, streaming, batch, MCP, and sandbox usage.
BLERBZ keeps legacy x-ratelimit-* headers for compatibility and also emits modern RateLimit-* headers where rate limiting is applied. Clients should prefer RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, and RateLimit-Policy, while continuing to tolerate X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, and X-RateLimit-Policy.
RateLimit-Limit is the request budget for the active window. RateLimit-Remaining is the number of requests left in that window. RateLimit-Reset is a Unix timestamp in seconds indicating when the window resets. RateLimit-Policy describes the policy in request-count and window units, such as 60;w=60.
When BLERBZ returns 429, clients should read Retry-After first and wait that many seconds before retrying. Agents should preserve cursor state, avoid retry storms, and use Idempotency-Key on retry-safe mutation endpoints.
Unauthenticated public discovery surfaces are intentionally generous and cacheable. Authenticated NUCLEUZ API access, streaming endpoints, batch calls, and MCP tool execution may have separate budgets. Batch requests are bounded by request count and only allow approved read-only GET targets.