Dashboards and trackers
Add new listings or price changes to an internal buying, inventory, or research view.
Webhook alerts
Send marketplace alerts to your own tools with webhooks.
Connect matching listings to a dashboard, tracker, team workflow, or automation you already use. Webhooks are included for every account.
Put each match where work happens
Webhooks are useful when an alert needs to become part of a workflow, not just another notification.
Team workflows
Send the same structured alert to a shared process so people can review and act together.
Your own automations
Trigger the next step in a tool you control after Classifindr finds a match.
Two useful events
Get the changes that matter
Each payload includes the search, match, price, source listing link, and optional cached thumbnail needed for your workflow. Secrets, signatures, coordinates, and scraper internals are never included. Listing text is preserved as supplied by the marketplace and bounded for size.
New listing matches
Receive the listing, search, match reason, and source link when a check finds a new match.
Price decreases
Track a listing that drops in price with its previous and current prices.
CloudEvents JSON
{
"type": "alert.listing.matched.v1",
"id": "wh_01JEXAMPLE",
"subject": "match_123",
"data": {
"schema_version": 1,
"listing": { "title": "Example camera", "price": "450.00", "currency": "USD" },
"change": { "type": "new_listing" }
}
}Simple setup
Create, verify, route, review
- 01
Create an endpoint in the web portal.
- 02
Save the whsec_ secret when it is shown once.
- 03
Verify the endpoint with a signed test event.
- 04
Assign the webhook to the searches you choose.
- 05
Review delivery history and redeliver when needed.
For receivers
Set up from a desktop browser
Create and verify a webhook in the desktop web portal, save the one-time whsec_ secret, then assign the active channel to your searches. Mobile can view and assign existing active webhooks, but setup and delivery management stay on the desktop web app.
If you prefer an API, the tenant endpoints are under /api/v1/webhook-endpoints. The published schemas and receiver examples below are the reference contract.
What your receiver should do
- 1. Accept `POST` requests over HTTPS and read the raw UTF-8 body.
- 2. Verify `Webhook-Id`, `Webhook-Timestamp`, and every `v1` signature before parsing JSON.
- 3. Reject timestamps outside five minutes and deduplicate by `Webhook-Id`.
- 4. Return a 2xx response quickly, then process the event asynchronously.
Built for safe, visible delivery
- Signed HTTPS requests: verify the raw request body with the one-time secret before processing it.
- Retries with visibility: temporary failures are retried, delivery attempts are recorded for 30 days, and repeated failures can pause an endpoint.
- At least once and unordered: deduplicate by
Webhook-Idand do not depend on event order.
- Secret rotation: rotate a secret from the portal without exposing the old value in responses.
- Web-only management: create, verify, rotate, inspect, and redeliver from the web portal. Mobile can view and assign active webhooks.
- Reachability, not ownership: a 2xx verification response proves signed reachability. Use only an endpoint you are allowed to configure.
For receivers
Return a 2xx response quickly, process asynchronously, allow a five-minute timestamp tolerance, and keep a processed-event record keyed by Webhook-Id.