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.
When to Use Rate Limits
Rate Limits belongs to the Getting Started section and covers design resilient clients under throughput constraints.
The page is written for developers and operators who need predictable video background removal behavior in production, not just a one-off demo request.
- Use Rate Limits when you are setting up a new RemoveBGVideo integration or onboarding another engineer.
- Convert each checklist item into a small staging test before enabling production traffic.
- Keep these defaults in your own backend configuration so UI clients do not need to understand every API detail.
Implementation Notes
Before you promote this workflow, test it with at least one short clip, one longer clip, and one visually difficult clip from your actual product or customer segment.
For support and debugging, persist the original input reference, selected model, output format, credit usage, and final job status alongside your internal user or project id.
- Do not ship with a personal sandbox API key in production.
- Do not skip failure-path testing; invalid files, insufficient credits, and transient worker errors need visible handling.
- Do not hardcode model and output defaults in multiple services without one owner for changes.
FAQ
| Question | Answer |
|---|---|
| Is Rate Limits required for every integration? | Use it when the topic affects your setup, quality target, or operational workflow. |
| What should I test before going live? | Verify success, failure, timeout, retry, and insufficient-credit paths with realistic video files and the same output format you plan to ship. |
| How does this connect to the rest of the API? | Most workflows connect upload or source URL handling, job creation, status polling, output retrieval, usage tracking, and operational logging. |