This is a draft for internal review. It is not legal advice and has not been reviewed by a lawyer. Do not treat it as binding.
Privacy Policy
What Reqbeat holds about the companies and job postings in its public corpus, what it holds about you as a customer, and what it does with each. These are two different kinds of data, handled two different ways — the distinction below is the one that matters most on this page.
Version 0.1.0-draft · Effective 28 August 2026 · Last generated September 14, 2026
Who this policy covers
Reqbeat is operated by Deal Baker Ltd, registered at International House, 64 Nile Street, London N1 7SR, United Kingdom (company number 14906367). This policy covers reqbeat.com and its subdomains (app., api., docs., status., mcp.).
Governing data-protection law: the UK GDPR and the Data Protection Act 2018, supervised by the Information Commissioner's Office (ICO).
The corpus: data about companies and postings
Reqbeat's product is built on a corpus of public job postings — postings on company applicant-tracking systems and public job boards. This is the data the API sells access to. It is not data about you, and it is not data about the people who applied to those postings.
- •Every value Reqbeat's API serves about a company or a job posting is read from a public job advertisement — a posting on a company's own applicant-tracking system, on a public job board, or on an aggregator that re-lists them. None of it is bought from a private database or a people-data broker.
- •LinkedIn's public job listings are one of those public sources, and a substantial part of the corpus is read from them. What is read there is the job advertisement, exactly as on any other board. The complete list of fields Reqbeat holds and serves is published at reqbeat.com/data-ethics, and the board a posting was detected on is itself one of those fields — so the origin of any row you are served is something you can inspect, not something you have to take on trust. A company may also be matched internally using a public LinkedIn handle as a join key; that handle is never itself returned.
- •No contact PII of any kind — no name, email address, phone number, or profile of a natural person — is ever served as a field. No field in the API's response schema is a person record. The one thing this cannot promise is the advertisement's own text, which is served verbatim as the employer published it: a contact detail an employer chose to print in their own public advert is in that text. Reqbeat neither extracts it, indexes it, nor builds a person record from it.
- •The corpus that backs Reqbeat's public research pages (reqbeat.com/method, reqbeat.com/data-ethics) is read through a separate, read-only connection that cannot reach a customer's account, usage, or queries at all — enforced at the code level and checked by an automated test on every change.
Every field Reqbeat holds about a posting
Every field the API serves about a posting, plus the few the public research pages derive or join on. Computed from the schema itself, not typed here by hand — see Data ethics for the full technical statement.
idurltitlestandard_titlecompany_idcompany_namecompany_domainlocationcountrycountry_codeposted_atsourcedescriptionskillsremote_typeremote_type_sourceremote_type_confidencesalary_rawsalary_minsalary_maxsalary_currencysalary_periodyearly_salary_usdseniority_levelapply_urlapply_typeapply_url_sourceapply_precisionats_providerleaves_siteexternal_reference_idemployer_typejob_familyposting_typecontact_personis_intermediatedemployer_disclosedis_canonical_sourceeligibilityrelevance_scoretitle_similaritycompany_signal_counthas_substantive_descriptionposted_at_precisionsalary_estimate_medianindustryheadcountposting_livenesslast_check_at
No field here is a person record. Reqbeat holds no name, email address, phone number, or profile of an individual as a field of a posting.
contact_person reads like an exception and
is audited as one: Despite the name, this carries no person: it is the PII-safe projection of the posting's on-behalf-of routing, and holds only two company identifiers — the agency's and the company the role was posted for. The underlying record's recruiter name, email address, phone number, LinkedIn profile and job title are deliberately never served.
One caveat we will not paper over. The `description` field is the advertisement's own text, stored and served exactly as the employer published it. Where an employer has chosen to print an individual's details in their own public job advert, those details are inside that text. We do not extract them, index them, build a person record from them, or publish them on this site — and we offer no way to search or filter on them. What we will not do is claim there is no field in which such a detail could appear, because that would not be true.
What the paid API can return about a company
A customer's API key can retrieve the following about a company or its requisitions — every one of these is company- or posting-level, never individual-level:
- •Company identity: name, domain, HQ country.
- •Hiring status: whether a company is currently hiring, and how many open requisitions it has.
- •Requisition detail: job title, function, country, first-seen date, and which job board(s) carried it.
- •The advertisement itself: the posting's own body text, returned verbatim as the employer published it, together with the apply link and the skills named in it. This is the employer's text, not Reqbeat's summary of it.
- •Hiring trend: rate and direction of hiring activity, first-hire timing by function, repost frequency, and ATS-vendor migration events.
- •Market aggregates: role demand across companies and time.
The research corpus behind reqbeat.com's public pages is read through a connection with no path back to any customer's account, usage history, or saved queries — see the provenance statements on Method. That separation is enforced in code, not policy, and is covered by an automated test.
What we hold about you, our customer
Creating a Reqbeat account requires an email address — we send a single-use magic link to it rather than asking for a password. From that point on we hold:
- •Your email address, used to sign you in and to reach you about your account.
- •Your API key, stored as a one-way hash — the raw key is shown once at issuance and never stored in a form we could read back.
- •Usage records: which endpoint you called, when, and how many billable units it cost. We do not log the contents of your requests or responses — only the metering metadata needed to bill accurately and show you your own usage.
- •A Stripe customer and subscription reference, so we can bill you. We never see or store your card details — Stripe holds those directly.
- •If you create a watch or a webhook: the search criteria or company you asked us to monitor, and the webhook URL (and signing secret) you gave us to deliver matches to.
- •Where you signed up from (e.g. a specific pricing page, a Clay integration, a search result) — attribution data we use to understand which parts of the product bring in customers.
What we do with your queries and webhook targets
Solely to deliver your own matching results to you. A saved search or webhook URL you configure is never shared with another customer, never sold, and never fed back into the research corpus Reqbeat publishes from — the code path that reads the research corpus cannot reach a customer record at all, by construction.
Retention
The research corpus surface behind reqbeat.com's public pages retains a rolling 30-day window on posting date (published on Method). The underlying signals database that powers features requiring a longer history — first-hire timing, ATS-vendor migration detection, repost patterns — retains job-posting data for longer than that window to support those features; this draft does not state a single retention ceiling for it.
Account data (your email, key, usage records, watch and webhook configuration) is retained for as long as your account is active, plus 90 days after closure. If you want your account data deleted, contact [email protected] — today this is a manual process; there is no self-serve deletion or data export in the product yet.
Cookies
The Reqbeat API and customer dashboard authenticate with an API key in a request header — neither sets a cookie.
reqbeat.com's marketing and documentation pages load Google Analytics (GA4), which sets first-party analytics cookies in your browser to measure site usage. No advertising or cross-site tracking cookies are set.
Who we share data with
We use a small number of processors to run the service:
- •Stripe — payment processing and billing. Stripe holds your payment details directly; we hold only an opaque customer reference.
- •Mailgun — sends your magic-link sign-in email and account notifications.
- •Google Analytics — site-usage analytics on our marketing pages only, never on the API or dashboard.
We do not sell your data. We do not share your account, usage, or query data with any other customer.
Your rights
Depending on where you're located, you may have the right to access, correct, or request deletion of the personal data we hold about you (your account data — see above; this does not apply to the corpus, which holds no personal data). To exercise any of these, email [email protected]. We handle these requests manually today.
Changes to this policy
We'll update this page when what we hold or what we do with it changes, and update the version number and generation date at the top.
Contact
Questions about this policy: [email protected].