Requests with many URLs run in the background. Every trigger returns a `dispatch_id`, and you
read status and results with it.
POST /webhook/check-job
Returns the state of a dispatch, and its results once finished.
curl -X POST https://api.jetscrape.com/webhook/check-job \
-H "Content-Type: application/json" \
-H "x-api-key: js_YOUR_API_KEY" \
-d '{ "dispatch_id": "disp_abc123" }'While the job is running:
{
"dispatch_id": "disp_abc123",
"status": "running",
"position": null,
"message": "Job is running"
}Once it has finished:
{
"dispatch_id": "disp_abc123",
"status": "completed",
"job": {
"id": 789,
"status": "completed",
"total_steps": 3,
"current_step": 3,
"created_at": "2025-06-08T10:00:00.000Z",
"completed_at": "2025-06-08T10:01:30.000Z"
},
"results": [
{
"ID": 1,
"PredefinedRequestId": 100,
"JobId": 789,
"Result": { "title": "Product Name", "price": "99.99" },
"CreatedAt": "2025-06-08T10:01:00.000Z"
}
]
}`Result` holds the extracted data, keyed by your `property_name` values. When network capture
is on, `network` and `network_dropped` sit alongside it.
GET /webhook/unblocker/job/:dispatchId
Gives progress and timing detail for the same job — what you want behind a progress bar.
curl "https://api.jetscrape.com/webhook/unblocker/job/disp_abc123" \
-H "x-api-key: js_YOUR_API_KEY"{
"job_id": 789,
"status": "running",
"progress": {
"completed": 5,
"failed": 0,
"total": 10,
"successful": 5,
"remaining": 5,
"percentage": 50.0
},
"timing": {
"elapsed_seconds": 12,
"avg_seconds_per_url": "2.4",
"eta_seconds": 12,
"started_at": "2025-06-08T10:00:00.000Z"
}
}{
"job_id": 789,
"status": "completed",
"progress": {
"completed": 10,
"failed": 0,
"total": 10,
"successful": 10,
"remaining": 0,
"percentage": 100.0
},
"timing": {
"elapsed_seconds": 25,
"started_at": "2025-06-08T10:00:00.000Z",
"completed_at": "2025-06-08T10:00:25.000Z"
}
}Status values
- `queued` — accepted, not started yet.
- `running` — in progress.
- `completed` — finished; `results` is ready.
- `failed` — the job failed.
How to poll
- Make the first call after 2–3 seconds, then back off (2 s, 4 s, 8 s).
- Do not poll more than once per second; progress is updated in batches anyway.
- If `timing.eta_seconds` is present, schedule the next call around it.
- Stop as soon as `status` is `completed` or `failed`.
Status queries do not consume credits.
A job can partially succeed. Even with `failed_count` above zero the successful rows are
returned — check `success` on each row and retry only the failed URLs.