Docs
Webhooks: job-posting events, pushed to your endpoint
The reference for Reqbeat's push delivery. For a guided 15-minute setup, use the webhook how-to; every endpoint and field is in the API reference.
The model: watches, not polling
A watch is a standing subscription: a company, or a saved search ("SDR roles in the UK"), paired with a webhook URL. Reqbeat re-reads its corpus every 3 hours across 7 regions; when something changes for a watch, your endpoint receives a signed POST carrying the event, the company, and the real posting with its source link. There is no polling loop to run and no dataset to diff — the diffing is the product.
Registering a watch
One call. The body is either a search (role, geo) or a single company:
curl -s -X POST 'https://api.reqbeat.com/v1/watches' \
-H "X-API-Key: $REQBEAT_API_KEY" \
-d '{"q": "sdr", "geo": "United Kingdom",
"webhook_url": "https://your-endpoint.example/wh/…"}'
Any endpoint that accepts a POST works: an n8n Webhook trigger, a Clay webhook table, a Zapier catch hook, or a route in your own app. Set a secret when you register the watch and every delivery is signed with the X-Plane-Signature header — verify it before acting on the payload.
The four event types
Every delivery names its event. The distinction matters, because a reposted ad is not a new opening:
opened— a new matching req was detected. This is the event to treat as a fresh trigger.reobserved— a req already delivered was seen again on a later read: the posting is still live.reposted— a req that had gone away returned. Not a new opening; do not re-trigger outbound on it.closed— the req is no longer observed at its source.
A delivery looks like this:
{
"event": "opened",
"company": "Braze",
"raw_title": "Senior Platform Software Engineer I",
"location": "London",
"detected_on": "greenhouse.io",
"url": "https://boards.greenhouse.io/…"
}Semantics your automation can rely on
- Deduplication is already done. A req syndicated across five boards arrives as one row per company, title and country, under the rule published on the method page. Building your own dedup on top will undo ours.
- Every event carries evidence. The payload links the real posting and names the board it was detected on — a rep, a client or an auditor can open it.
- Billing follows acceptance. A watch bills only when your endpoint accepts a delivery; duplicates and failed deliveries cost nothing.
- Unknown is never no. A company with no observable ATS or board coverage is reported as
coverage_status: "no_ats_signal"— unknown, never "not hiring". - The feed is forward-only. Changes past your plan's monthly delivered-changes allowance are not delivered and are not queued for later — there is no backlog to replay — and your console says when one was stopped.
Limits by plan
Watches count while they are live, so cancelling one frees the slot; delivered changes count against the billing month and refill when it turns.
| Plan | Live watches | Delivered changes / month |
|---|---|---|
| Free | 3 | 50 |
| Starter | 5 | 250 |
| Growth | 25 | 1,500 |
Each watch also carries its own max_fires_per_hour setting. A watch that fires more often than that has its extra deliveries dropped with the delivery status rate_limited — a setting on the watch, not your API request rate, and it never arrives as an HTTP 429. Full plan details are on pricing.
The same signals, pulled instead
Webhooks are one delivery mode. The same corpus answers REST queries (quickstart), serves agents over MCP, and feeds Clay and n8n recipes. If you are comparing push providers before committing, the honest rundown is real-time job posting webhook APIs, compared.
Register one watch on the free tier and let the first delivery argue for itself.
Start free. No credit card.