API Reference
Job Status
Query status and output information for a job.
Endpoint
GET /v1/jobs/{job_id}
Example Request
curl -X GET https://api.removebgvideo.com/v1/jobs/{job_id} \
-H "X-Api-Key: YOUR_API_KEY"Status Values
| Status | Meaning |
|---|---|
| pending | Accepted, waiting for processing |
| processing | RunPod worker is processing |
| completed | Output available |
| failed | Job failed, check error |
Response Fields
| Field | Type | Description |
|---|---|---|
| id | string | Job id |
| status | string | Job status |
| progress | number | 0-100 progress |
| output_url | string|null | Processed asset URL when completed |
| error | string|null | Error message when failed |
| created_at | string | UTC time |
| duration_seconds | number|null | Output duration |
| billing_status | string|null | Credit charge status |
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 |
Status Polling Policy
- Start with 2s interval, back off to 5-10s for long jobs.
- Stop polling on completed/failed terminal states.
- Persist last known status to survive worker restarts.