Skip to main content
Use an async job when a caller should not hold an HTTP connection open while Chromium renders the page. POST /render is always asynchronous. Snapshot and screenshot requests become asynchronous when async is true or a webhookUrl is supplied.

Submit a job

Async jobs always store their screenshot, so include storage_path when requesting one.

Poll job status

Call GET /status/{jobId} with the same account key that created the job. Status is queued, in_progress, completed, failed, or not_found, and progress ranges from 0 to 100.
The endpoint returns 401 for a missing, unknown, or revoked API key. A nonexistent job and a job owned by another account both return 404; ownership is never disclosed. Completed results stored in job state are capped at about 1.5 MB. If necessary, Scrinly drops the largest optional fields and lists their names in result.truncated. Stored media URLs remain available.

Receive a webhook

Set webhookUrl to receive the final job result instead of polling. It implies async mode. If you also set webhookSecret, Scrinly signs the raw request body with HMAC-SHA256. Verify the signature before parsing or trusting the payload. Your webhook should return a successful response quickly and move expensive processing to its own queue. Delivery failures do not change the completed render result.

Retry failures

  • POST /retry/{jobId} re-enqueues one failed job.
  • POST /retry-failed retries failed jobs in bulk.
  • GET /dead-letter-queue lists jobs that exhausted normal delivery attempts.
These routes are customer-authenticated and account-scoped. A retry can consume credits because it performs Browser Rendering again.