Guide

How to get a webhook when a company posts a job

One API call registers the watch. From then on, each new matching req is posted to your endpoint with the real posting and its ATS link. About 15 minutes end to end.

What you are building

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, and when a new matching posting is detected your endpoint receives a signed POST — the company, the posting title, the board it was detected on, and the URL of the real req. No polling loop, no scraper to babysit, no CSV to diff.

If you have never worked with hiring signals before, the hiring signals guide covers why a new req is worth reacting to; this page is just the plumbing. The reference version — event types, signatures, limits — lives in the webhook docs.

Step 1: get a key and an endpoint

Sign up free — no card — and copy your API key from the dashboard. The free tier includes 3 live watches and 50 delivered changes a month, which covers this whole guide.

Your endpoint can be anything that accepts a POST: 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 (X-Plane-Signature), so you can verify it before acting.

Step 2: register the watch

One call. A watch can cover a role-and-country search across every company, or a single account you sell to:

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/…"}'

Step 3: read the delivery

Each delivery names its event and carries the evidence:

{
  "event": "req.detected",
  "company": "Braze",
  "raw_title": "Senior Platform Software Engineer I",
  "location": "London",
  "detected_on": "greenhouse.io",
  "url": "https://boards.greenhouse.io/…"
}

Four things to know about the stream so your automation does not fool itself:

  • Event types. Deliveries distinguish opened, reobserved, reposted and closed. A re-posted ad is not a new opening — treat only opened as a fresh trigger.
  • Deduplication is already done. The same req syndicated across five boards arrives as one row per company, title and country, under the rule published on the method page. Do not build your own dedup on top; you will undo ours.
  • Billing follows acceptance. A watch bills only when your endpoint accepts a delivery; duplicates and failed deliveries cost nothing.
  • Unknown is never no. If a company has no ATS or board coverage we can observe, the API says coverage_status: "no_ats_signal". That means unknown — never route it as "not hiring".

Step 4: wire it into the tool you already run

From here it is ordinary automation. The Clay recipe turns each delivery into an enriched row and a same-day email with the ATS link as the receipt; the n8n recipe fans one stream out across client lists; agents can skip webhooks entirely and consume the same signals over MCP. The quickstart has the REST calls if you would rather pull than be pushed.

Other ways to get there

In the spirit of the comparison pages: you can also get job-posting webhooks from TheirStack (attached to saved searches, on their API plans) and PredictLeads (part of their multi-signal platform), or build your own by polling a jobs API from an n8n cron and diffing results — fine for one company, painful at fifty once duplicates and repostings enter. The honest trade-offs between all of these are compared provider by provider in real-time job posting webhook APIs and on the alternatives page; the short version is that a webhook with a published dedup rule and an evidence link is the version you can defend to a rep, a client, or an auditor.

Your first webhook can fire this afternoon. One curl, then watch your endpoint.

Get an API key Connect via MCP

Start free. No credit card.