Getting Started
Rate Limits
Design resilient clients under throughput constraints.
How Limits Work
Rate limits are applied per API key and may vary by plan and system load.
Use queue-based dispatch for high-volume tasks.
Client Strategy
- Cap concurrent in-flight jobs.
- Use exponential backoff with jitter on 429.
- Add circuit breaker when upstream errors surge.
Backoff Policy Example
| Attempt | Delay |
|---|---|
| 1 | 1-2s |
| 2 | 2-4s |
| 3 | 4-8s |
| 4+ | 8-16s (max cap) |
Production Readiness
- Pin SDK/API versions in deployment manifests and release notes.
- Record request_id/job_id in logs for every API interaction.
- Run smoke tests after each deploy using a known short test video.
- Separate dev/staging/prod keys and rotate keys regularly.
Tip: Treat docs examples as baseline templates; finalize payload defaults in your own backend policy layer.
Acceptance Checklist
- Validate one success path and one failure path end-to-end.
- Confirm credits, usage metrics, and output links are consistent.
- Set retry and timeout policy for 429/5xx response handling.
- Document rollback procedure for integration incidents.
Rate-Limit Safe Client Strategy
- Implement token bucket or leaky bucket in worker layer.
- Use jittered exponential backoff for 429 responses.
- Separate polling traffic from create/start traffic to avoid contention.