Concurrency Quotas & Rate Limiting
The platform allocates the following limits per account, based on the plan tier:
Rate-limit mitigation patterns:
- Use a local client queue + token bucket to control the send rate
- Apply exponential backoff retry on 429
- Use WebHook for long tasks to avoid occupying HTTP connections
Data Retention & Security
Content Moderation
The platform performs automatic content moderation on input prompts, uploaded images, and generated results:audit_status: 1Not reviewed (should not appear in terminal-state tasks)audit_status: 2Approvedaudit_status: 3Rejected; result is inaccessibleaudit_status: 4Moderation error (e.g., input inaccessible)
Billing & Balance
Billing Method
Fee =inference_cost_time × the app’s unit price. Includes:
- ✅ Inference time (
Runningstage) - ❌ Does not include queueing, preparation, upload, or download time
- ❌ Does not include
Canceledtasks - ✅ Includes inference time consumed before an interruption
Querying Balance
Low-balance Alert
It’s recommended to poll the balance periodically (e.g., hourly) at the application layer and trigger an alert when it drops below a threshold, to avoid production disruption caused by insufficient balance.Monitoring & Observability
Recommended metrics to monitor:Drills & Disaster Preparedness
Drill Checklist
- Periodically drill a fast API Key rotation after a leak (create → deploy → delete old key)
- Drill a progressive 429 degradation (reduce concurrency, apply backpressure upstream)
- Drill progressive WebHook callback failure (fall back to polling)
Readiness Checklist
Confirm before going live:- API Key stored in a secrets management service, not hard-coded
- Synchronous blocking call client read timeout ≥ 60s
- WebHook receiver verifies the
X-BizyAir-Task-Authorizationheader - WebHook receiver implements idempotency (guard against duplicate callbacks)
- Important outputs are transferred to your own OSS / S3 storage in real time
- Low-balance alerts configured
- Retry and degradation logic in place