API ReferenceFetch Bulk

Bulk fetch URLs

Enqueues multiple URLs for HTTP fetching. Results delivered via webhook. Does not support options that require page rendering (wait_for_selector, etc.). Completion deliveries use X-ByteKit-Event: bulk.completed and the BulkCompletedWebhook contract: at most 500 complete items and 1 MiB, followed by cursor recovery through GET /v1/fetch/bulk/{id} whenever recovery_required is true.

Limits: request bodies are guarded in a two-tier shape. A streamed body with no Content-Length header is capped at 2 MB before your API key is checked; a body that declares Content-Length is instead bounded there by a 20 MB fail-safe (not the real limit — see below), since that branch reads nothing until your key is verified. Once your key is verified, a second check re-gates the body against your account's own max_bulk_size (at this endpoint's per-item override budget), which reaches 16.8 MB for the largest documented account. A standard-plan account's effective ceiling is 2 MB; either tier's overrun returns a 400 with error code request_too_large.

For AI agents: https://bytekit.com/llms.txt — every docs page is available as markdown by appending .md

POST
/v1/fetch/bulk

Authorization

AuthorizationRequiredBearer <token>

API key. Manage keys from the dashboard at app.bytekit.com.

In: header

Request Body

application/jsonRequired
urlsRequiredarray<string | object>
defaultsobject
webhook_urlRequiredstring

Webhook endpoint URL (HTTPS only; http:// rejected with 400 invalid_url, reason scheme_unsupported)

Pattern: "^https://"Format: "uri"
webhook_secretstring

HMAC secret used to sign webhook deliveries. Each delivery carries X-Webhook-Timestamp and X-Webhook-Signature (sha256= + the hex HMAC-SHA256 of timestamp.body). See https://bytekit.com/docs/guides/webhooks for verification code.

metadataobject

Arbitrary key-value metadata. Max 4096 bytes when JSON-serialized.

curl -X POST https://api.bytekit.com/v1/fetch/bulk \
  -H "Authorization: Bearer sk_live_your_api_key_here"

Fetch bulk job accepted.

{
  "id": "bulk_01j9abc123",
  "status": "processing",
  "total": 0,
  "completed": 0,
  "failed": 0,
  "created_at": "2019-08-24T14:15:22Z",
  "completed_at": "2019-08-24T14:15:22Z",
  "total_credits_charged": 0,
  "total_billed_bytes": 0,
  "estimated_credits": 0,
  "webhook_url": "string"
}

Fetch Bulk

Fetch Bulk API — endpoints, requests, and responses.

GET /v1/fetch/bulk/{id}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`.