Webhooks

Scrape results do not come in by polling. When Scrape Admin has scraped an offer, it sends the result to the platform with a webhook. The platform checks it, updates the offer's price, stock and status, adds a price history point when the price changed, and logs the delivery.

How results arrive

Each offer has its own destination:

POST /api/webhooks/scrape-admin/offers/{offerId}
Authorization: Bearer <webhook secret>

The platform sets this up for you when it syncs an offer's entry to Scrape Admin, together with the project's webhook secret, so you normally do not configure anything by hand. See Connect Scrape Admin for the secret and how it is rotated.

A request is handled in this order:

1. The offer id must exist, otherwise the delivery is logged as Unknown offer.
2. The bearer token must match the project's webhook secret (the previous one is also accepted for 24 hours after a rotation), otherwise Bad secret.
3. The body must be a valid scrape result and no larger than 256 KB, otherwise Invalid payload.
4. The same body for the same offer within 10 minutes is acknowledged and dropped as a Duplicate.
5. Otherwise the result is applied and logged as Processed. If applying it fails, it is logged as Failed.

Which results Scrape Admin delivers is set per offer with its Webhook trigger (on change, on every run, or custom code), see Offers. An offer without one delivers on change. Results that did not change are only delivered when the trigger asks for them.

What a processed result does depends on the project's configuration: the price and stock attributes it reads, the status codes that deactivate the offer, and whether redirects update the URL.

The delivery log

Open an offer, click Diagnose and choose the Deliveries tab. It lists every result Scrape Admin sent for that offer, newest first, ten per page. Each row shows:

• the status: Processed, Duplicate, Bad secret, Invalid payload, Unknown offer or Failed;
• the HTTP status the platform answered with and how long it took;
• a replay badge if the row is itself a replay;
• when it was received, any error, and the fields it Changed, such as the price.

Click a row to expand it. You see the normalized result, which is what the platform understood, and the raw body as sent. Deliveries that were rejected before authentication, and duplicates, have no stored payload.

When nothing is listed, the offer has not received a result yet. If the project is connected, check the Scrape Admin tab in the same dialog for failed runs: runs that fail inside Scrape Admin never send a webhook, which is why an offer can become Stale instead.

Replay a delivery

Admins can click Replay on an expanded delivery. The platform runs the stored body through the same processing again, as if it had just arrived, and logs a new delivery marked as a replay. A toast tells you which fields changed, or that nothing changed.

Replay is useful after you changed the configuration, for example the price attributes or status codes, or after fixing a currency problem, and want an earlier result to be applied under the new rules. It only works while the delivery has a stored body and the offer still exists.