Receive and verify Scrapfly webhooks. Use when setting up Scrapfly webhook handlers for async scrape, extraction, screenshot, or crawler jobs, debugging X-Scrapfly-Webhook-Signature verification, or routing on X-Scrapfly-Webhook-Resource-Type.
Receive and verify Scrapfly webhooks. Use when setting up Scrapfly webhook handlers for async scrape, extraction, screenshot, or crawler jobs, debugging X-Scrapfly-Webhook-Signature verification, or routing on X-Scrapfly-Webhook-Resource-Type.
How do I handle async Scrape API, Extraction API, or Screenshot API results?
How do I route Scrapfly webhooks by resource type (scrape, extraction, screenshot)?
How do I handle Crawler API webhook events (crawler_started, crawler_finished, ...)?
Why is my Scrapfly webhook signature verification failing?
Prerequisites
A paid Scrapfly plan. Webhooks are not available on the FREE plan — its webhook queue size is 0, so no deliveries are ever dispatched even after configuration. The dashboard hides the webhook UI on the free tier. Any paid tier enables delivery. See references/setup.md for the full plan-detection checklist.
How Scrapfly Webhooks Work
Scrapfly uses HMAC-SHA256 with uppercase hex encoding over the raw request body. There is no SDK for webhook verification — implementations follow Scrapfly's documented algorithm.
Key facts:
Signature header: X-Scrapfly-Webhook-Signature (uppercase hex). A duplicate X-Scrapfly-Webhook-Signature-Lowercase is also sent for runtimes that normalise headers.
What is signed: The raw request body bytes. Do not parse and re-serialise JSON — that changes the byte sequence and breaks the signature.
No timestamp / replay window: Scrapfly does not include a timestamp header; treat the signature as authenticity-only.
Secret: Use the value from the Scrapfly dashboard exactly as shown. Do not trim or base64-decode it.
Routing: Use X-Scrapfly-Webhook-Resource-Type (scrape, extraction, screenshot) to dispatch when one endpoint serves multiple products. Crawler events also carry X-Scrapfly-Crawl-Event-Name and an event field in the body.
Content-Type is whatever you configured in the dashboard, not what the body actually is. Scrapfly's webhook config has a Content-Type dropdown (application/json or application/msgpack) and sends the chosen value on every delivery — but it doesn't change what's in the body for image deliveries. Screenshot API deliveries carry raw image bytes (JPEG/PNG/WebP/GIF) regardless of the configured Content-Type, so the header is unreliable for that resource type. Dispatch on X-Scrapfly-Webhook-Resource-Type, not on Content-Type, and parse only after dispatching. HMAC verification works fine over any body — only the parse step needs to know whether it's a JSON, msgpack, or binary body. This skill's example handlers assume the dashboard is configured to application/json; if you pick msgpack, swap JSON.parse / json.loads for a msgpack decoder.
Hookdeck Event Gateway alternative: If you're already routing webhooks through Hookdeck (the hookdeck-event-gateway skill recommends this), set the source type to SCRAPFLY on the gateway connection and Hookdeck verifies the Scrapfly signature at the edge. Your handler then only needs to verify Hookdeck's signature, not Scrapfly's directly.
We recommend installing the webhook-handler-patterns skill alongside this one for handler sequence, idempotency, error handling, and retry logic. Key references (open on GitHub):
Handler sequence — Verify first, parse second, handle idempotently third
Idempotency — Prevent duplicate processing (use X-Scrapfly-Webhook-Id or X-Scrapfly-Webhook-Job-Id as the key)
Error handling — Return codes, logging, dead letter queues
hookdeck-event-gateway - Webhook infrastructure that replaces your queue — guaranteed delivery, automatic retries, replay, rate limiting, and observability for your webhook handlers
