Hello, Reqbeat: watch the accounts you sell to

Reqbeat is live. You give it the accounts you sell to. It watches their hiring pages. When a company posts a new job requisition, it sends your endpoint a webhook with the real posting and the ATS link. That is the whole product, and today it is open to everyone.

What Reqbeat is

A watch is the core object. You save a watch for one account, or for a role and country across every company. From that moment, Reqbeat checks the public hiring surfaces that cover it: ATS tenants, public job boards and aggregators. The corpus refreshes every 3 hours across 7 regions.

When a new matching posting is detected, a webhook fires, typically hours after the posting goes live. The payload is not a score. It carries the company, the posting title, the location, the board it was detected on, and the URL of the posting itself. You can open the link and read the req your prospect just published.

Deliveries are signed. You set a secret when you register the endpoint and verify the X-Plane-Signature header on each delivery. A watch bills only when your endpoint accepts a delivered change. Duplicates and failed deliveries cost nothing.

Why we built it

GTM teams buy intent data they cannot check. A topic score says an account "surged" last week. You cannot open the surge. You cannot forward it to a prospect. By the time it reaches your CRM, it is already stale.

A public job posting is different. It is committed budget, written down, in public. A company that opens a req for an SDR manager has decided to spend money on that problem. The pain is named in the text of the posting. Anyone on your team can click the link and verify it.

Timing is the other half. The team that reaches an account while the req is still new has a different conversation than the team that arrives after the hire is made. A signal like that has to move at the speed of a webhook, not a weekly export.

We wanted that signal as a primitive: fresh, deduplicated, and delivered to wherever your workflow already lives. So we built the watcher first and the website second.

What exists today

Everything below is live now, not on a roadmap.

• Watches and webhooks. Save a watch. Receive signed deliveries when a matching req appears.
• REST. Pull the same data on your own schedule: search companies, read postings, check hiring pulse.
• Clay. A watch delivers straight into a webhook-source table. The same-day outreach recipe goes from zero to a live loop in about 30 minutes.
• n8n. Build weekly segment refreshes on REST. The weekly client segments recipe shows the full flow.
• MCP. An MCP server your agents call directly. Start with the hiring-pulse agent recipe or the MCP page.
• A free tier, no card. Signup puts a key on screen. The free tier is permanent and covers 3 watches.
• A 14-day trial at signup. Signup grants a trial on top of the free tier, no card. Copy the key on screen and try the data over REST or MCP the same hour.

Billing follows the same rule everywhere: you pay for accepted value, nothing else. Searches bill per sourced company row, an empty result costs nothing, and every self-serve plan ships with a hard spend cap already set. Full detail is on pricing.

The quickstart takes you from nothing to a first signal in about 5 minutes. The FAQ covers data sources, billing, caps and rate limits in short answers. Full API detail lives in the docs.

What is next

We ship in public. The changelog lists every site surface we release, newest first. The method page versions every change to data and metrics, with no silent edits. When something new lands, it appears there first.

If you sell to companies, and those companies hire, start with one watch on one account. The first webhook makes the case better than this post can.