# Get fetch bulk job status

Returns the job envelope plus its per-URL items.

**Downloading item content.** Each completed item's `content_url` is a
**pre-signed** URL, minted fresh on every read of this endpoint and valid
for **600 seconds (10 minutes)** — the same signing lifetime as the
`image_url` returned by `GET /v1/bulk/{id}/screenshots`. The underlying
objects are private, so an unsigned URL returns `401`: download the
content inside that window, or re-poll this endpoint for a fresh
signature. Items that are not `completed`, and completed items with no
stored object, or completed items whose object cannot be signed, carry
`null`; the latter report `artifact_unavailable`. The private unsigned
storage URL is never returned.

**Cancelled by the platform.** When the account can no longer spend (its bandwidth
balance is exhausted, or the account is deleted) while items are still pending, ByteKit
cancels the job itself. It then reads `status: cancelled` even though you never called
`DELETE /v1/bulk/{id}`, and the cancellation sends no webhook.

**Job ids from other create routes.** The job is looked up by account only, so the id
of a job created by `POST /v1/scrape/bulk` or `POST /v1/bulk` is found here too, not a
`404`, with the job envelope and `items: []`: only items fetched through
`POST /v1/fetch/bulk` are listed. An id from another account answers `404`.

**GET** `/v1/fetch/bulk/{id}`

## Parameters

- `id` (path, string, required)
- `cursor` (query, string) — Opaque cursor returned by the preceding page. It is bound to this bulk id, this recovery route, and the exact status filter; cross-scope cursors return 422.
- `limit` (query, integer) — Maximum result rows considered for this page; the 16-MiB response bound may stop sooner.
- `status` (query, string) — Optional item-status filter. A cursor may be reused only with the same filter.

## Responses

### 200 — Successful response.
- `id`
- `status`
- `total`
- `completed`
- `failed`
- `created_at`
- `completed_at`
- `total_credits_charged`
- `total_billed_bytes`
- `estimated_credits`
- `webhook_url`
- `next_cursor`
- `has_more`
- `items`
- `items.id`
- `items.url`
- `items.status`
- `items.content_type`
- `items.content_length`
- `items.content_url`
- `items.waf_vendor`
- `items.cache_hit`
- `items.billing`
- `items.billing.raw_bytes`
- `items.billing.factors`
- `items.billing.factors.name`
- `items.billing.factors.value`
- `items.billing.factors.reason`
- `items.billing.multiplier`
- `items.billing.billed_bytes`
- `items.error_code`
- `items.error_message`
- `items.created_at`
- `items.completed_at`
- `items.type`
- `items.terminal_outcome`

### 202 — Bulk job still processing. The poll answers 200 for a job in
`BULK_TERMINAL_STATUSES` (`completed`, `failed`, `cancelled`) and 202
otherwise, over an identical body, so this is the SAME envelope the 200
documents — only the status code and the reachable `status` values
differ. Keep polling until you get a 200; a **cancelled** job is served
200, not 202 (issues #3533, #4754).

Item `content_url` values are pre-signed exactly as on the 200 — a fresh
600-second signature on every poll.
- `id`
- `status`
- `total`
- `completed`
- `failed`
- `created_at`
- `completed_at`
- `total_credits_charged`
- `total_billed_bytes`
- `estimated_credits`
- `webhook_url`
- `next_cursor`
- `has_more`
- `items`
- `items.id`
- `items.url`
- `items.status`
- `items.content_type`
- `items.content_length`
- `items.content_url`
- `items.waf_vendor`
- `items.cache_hit`
- `items.billing`
- `items.billing.raw_bytes`
- `items.billing.factors`
- `items.billing.factors.name`
- `items.billing.factors.value`
- `items.billing.factors.reason`
- `items.billing.multiplier`
- `items.billing.billed_bytes`
- `items.error_code`
- `items.error_message`
- `items.created_at`
- `items.completed_at`
- `items.type`
- `items.terminal_outcome`

### 401 — Unauthorized. The request carried no valid credential, and no work was
performed. The unified `Error` envelope carries one of the codes below
in `error.code`; match on the code, never on the prose.

- `invalid_api_key` — a bearer API key was presented and rejected:
  unknown, revoked, expired or malformed. The bearer-only operations
  (`/v1/webhook-deliveries*` among them) also return it when no
  `Authorization` header is sent. `GET /v1/account` is the exception
  to "malformed": it returns `invalid_api_key` only for a key that
  starts `sk_test_` or `sk_live_` and is unknown, revoked or expired.
- `unauthorized` — the `Authorization` header is absent or malformed on
  an operation that also accepts a dashboard session (the dual-auth and
  billing operations). `GET /v1/account` also returns it, for no
  `Authorization` header and for any bearer value that does not start
  `sk_test_` or `sk_live_` (that value is checked as a dashboard
  session token).

Not retryable as-is: supply a valid API key first.
- `status`
- `error`
- `error.code`
- `error.message`
- `error.http_status`
- `error.failed_at`
- `error.details`

### 404 — Resource not found.
- `status`
- `error`
- `error.code`
- `error.message`
- `error.http_status`
- `error.failed_at`
- `error.details`