API Reference

Responses & Errors

Error schema and recommended handling strategies.

Error Schema

{
  "error": {
    "code": "insufficient_credits",
    "message": "Not enough credits to process this video",
    "request_id": "req_123456"
  }
}

Common Error Cases

Endpoint	HTTP	Example Message	Action
/api/upload	400	Invalid file type	Use supported video MIME
/api/upload	400	File too large	Keep file <= 500MB
/v1/jobs/{job_id}	404	Job not found	Check job id and key ownership
/api/download/{job_id}	400	Job not completed	Poll status until completed
/v1/jobs	500	Processing failed	Retry with backoff

Logging Recommendations

Log job_id for every process/status/download call.
Log upstream RunPod errors with correlation id.
Emit structured logs for retries and final failures.

API Contract Notes

All clients should handle non-2xx responses as structured error payloads.
Use explicit JSON schema validation for request payloads on your side.
Treat output_url as an asynchronous artifact and not an immediate response contract.
Persist job lifecycle state transitions for auditing and support.

Integration Verification

Check	How to Verify
Authentication	Call endpoint with valid and invalid key, confirm 200 vs 401
Rate limits	Burst test and confirm 429 handling with backoff
Idempotency	Retry same request and verify no duplicate side effects
Observability	Confirm request_id/job_id appears in logs and dashboards

Error Classification

Class	Examples	Action
Client Errors (4xx)	invalid_request, invalid_api_key	Fix payload/config
Capacity/Limit	rate_limited, insufficient_credits	Retry/backoff or top-up
Server Errors (5xx)	internal_error, timeout	Retry with fallback and alerting

When to Use Responses & Errors

Responses & Errors belongs to the API Reference section and covers error schema and recommended handling strategies.

The page is written for developers and operators who need predictable video background removal behavior in production, not just a one-off demo request.

Validate the exact Responses & Errors contract before wiring it into backend workers or customer-facing flows.
Use the field tables and examples to create request/response tests in staging.
Capture job_id, request_id, model, output_format, and user context whenever this endpoint participates in a production workflow.

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 assume a processing request returns a finished video immediately; completed output is asynchronous.
Do not discard failed-job payloads before logging the error code and request context.
Do not let polling loops run without timeout, backoff, or terminal-state handling.

Page	Why It Matters
Health	Continue with api reference context: /docs/api-reference/health/
Introduction	Continue with api reference context: /docs/api-reference/introduction/
API Overview	Return to the developer API overview: /api/

FAQ

Question	Answer
Is Responses & Errors required for every integration?	Use it when your integration calls this endpoint directly; otherwise review it to understand the contract behind SDK helpers.
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.

Public API v1 Admin

Client