Privacy Policy

This policy explains what personal data we hold about you, why, and what you can do about it. It covers two different things: the data we collect when you use the portal and the API, and the personal data that occasionally turns up inside job postings in our dataset. Section 7 deals with the second one, and it is the part most people come here to read.

1. Who we are#

The data controller is ANTARES, based in Salerno, Italy (VAT 06439710655).

We have not designated a Data Protection Officer. We are not a public authority, our core activity is not large-scale monitoring of individuals, and we do not process special-category data at scale, so the criteria in Article 37 GDPR are not met. Privacy questions still go to a real address that a person reads: [email protected].

2. What this policy covers#

It covers the HyperJobs portal at hyperjobs.io, the API at api.hyperjobs.io, and the job dataset behind them.

HyperJobs is a business product sold to businesses and developers. It is not a job board and not a job-seeker service. There is no application feature, no CV upload, and no candidate profile. If you are looking for the part of this policy that explains what we do with applicants' data: we do not have applicants' data, because nobody applies for anything through us.

3. Data we collect about you#

Account data#

When you register we store your email address, and — if you sign in with Google — the display name and profile photo URL your Google account exposes. You may add a company name. We also keep whether your email is verified, your role, and timestamps for creation, update, and last login.

Authentication itself runs on Google Firebase Authentication. If you use a password, we never see it: Firebase holds the credential, and it never reaches our servers or our database.

Billing data#

Paid plans run through Stripe. We do not store your card number. Stripe does. We keep your Stripe customer id, your plan, subscription status, billing interval, start and end dates, whether it is set to cancel at period end, and a record of billing events — invoice ids, amounts, currency, event type. That is enough to show you your plan and to keep our books; it is not enough to charge a card.

API usage data#

We count requests per key per day. That is the whole of it: a key id, a date, and a number. We use it to enforce your quota, draw the charts in your dashboard, and bill correctly. We do not log the content of your API queries against your identity as a matter of course.

For each key we also hold the name you gave it, its scopes, when it was created, when it was last used, and whether it is revoked — plus a SHA-256 hash of the key and its short display prefix. We never store the key itself and cannot recover it.

Session and security data#

When you sign in we record a session: a session id, browser and operating system parsed from your user agent, your IP address, and an approximate city, region and country resolved from that IP. This is what the security page in your dashboard shows you, so you can spot a session you do not recognise.

To resolve the location we send your IP address to ip-api.com, a third-party geolocation service. It receives the IP and returns a city, region, and country. It is listed in Subprocessors.

We also keep an append-only log of authentication events — sign-in, failed sign-in, sign-out, and similar — with the event type, timestamp, IP, user agent, and the device fingerprint described below.

Device fingerprint and signup IP#

This is the part worth being specific about, because it is the part people assume the worst about.

We record the IP address you signed up from, and a device fingerprint — a visitor id plus the component values it was computed from (things like screen dimensions, timezone, installed fonts, and GPU string). We store the fingerprint at signup and with each sign-in.

The fingerprint is produced by the open-source FingerprintJS library, which runs entirely in your browser. No data is sent to FingerprintJS. They are not involved, they receive nothing, and they are not a subprocessor of ours. The library computes an identifier locally and hands it to our page; only then does it reach our server, like any other form field.

We use it for abuse prevention only. Concretely: spotting when one person farms many accounts to multiply a free quota. It is a signal a human looks at during an investigation.

In the EU/EEA, the UK, and Switzerland we ask first, and the legal basis is your consent (Article 6(1)(a)). Reading characteristics from your device engages Article 5(3) of the ePrivacy Directive whether or not a cookie is involved, so the cookie banner asks about exactly this, and declining means the fingerprint is never computed — the check runs before the library loads, not after. Withdraw it any time from Cookie settings in the footer; withdrawal is as easy as consent and takes effect immediately.

Everywhere else the basis is legitimate interests, Article 6(1)(f) — keeping a metered free tier from being drained by bulk account creation, which is what lets us offer one at all. The same controls sit in the footer, and you can object; see sections 8 and 9.

We could have leaned on the strictly-necessary exemption everywhere and shown no banner. We decided not to: the exemption for fraud prevention is genuinely contested, and we would rather lose a signal than assume a permission.

Related, and in the same spirit: at signup we limit how many accounts may be created from one IP address (3 per hour, 10 per 30 days), and we block disposable email domains using a static list and the DeBounce API, which receives the email address you typed. DeBounce is a subprocessor.

Product analytics#

We use PostHog to measure how the site is used — how many people read the quickstart, where they stop, what they searched the docs for. It runs in one of two modes, and which one you get is entirely your choice at the cookie banner. Cookie Policy has the full detail; this is what it means for your data.

If you consent, PostHog stores an id on your device (a ph_* cookie and localStorage), creates a person profile, links the pages you read before signing up to your account through an identify() call on your user id, and records session replay — a reconstruction of what happened in your browser window.

If you do not, PostHog still runs, and we would rather write that here than let you find it. It runs with persistence: 'memory' (nothing is written to your device), never calls identify(), creates no person profile at all, and records no replay. That is anonymous, aggregate counting.

In both modes we collect: the events listed below, page URLs, referrer, browser and device characteristics, and — where you are identified — your user id. Your IP address is not sent to PostHog in either mode (ip: false); PostHog never receives it.

The events are a short, fixed list, not a general capture of everything you do: docs_search, docs_search_empty, docs_page_helpful, pricing_plan_selected, signup_started, checkout_started from the browser, and signup_completed, api_key_created, api_first_request, plan_purchased, plan_changed, subscription_cancelled from our backend. Properties are ids, plan names, and counts. We do not put your email address or your name into an event.

Traffic reaches PostHog through a reverse proxy on our own domain (/ingest) rather than from your browser to a PostHog domain. That changes who your browser connects to, not who processes the data: PostHog is a subprocessor, listed in Subprocessors, and processes on their EU cloud in Germany.

Analytics about your account, from our servers#

Some events are sent to PostHog by our own backend rather than your browser: signup_completed, api_key_created, api_first_request, plan_purchased, plan_changed, subscription_cancelled. They carry your user id, a plan name, and counts.

These are not gated by the cookie banner, and you should know that from this page rather than from a network tab. The banner is an ePrivacy Article 5(3) question — it governs storing information on your device and reading information from it. This path touches no device: it records that an account we have a contract with created a key or bought a plan, from our own backend, out of our own database. plan_purchased fires from the Stripe webhook, where there is no browser in the path at all. Declining a cookie does not un-sell a subscription.

It is still processing of personal data, so it still needs a basis, and it has one: legitimate interests (Art. 6(1)(f)) in knowing whether our own product works, and contract (Art. 6(1)(b)) for the billing events we would be recording regardless. You can object under Article 21 — see sections 8 and 9.

Newsletter and marketing email#

We are building a developer newsletter. If you subscribe, we store your email address, where you subscribed from (a short source tag like blog-index or docs), and the timestamps that make the record meaningful: when you subscribed, when you confirmed, and when you unsubscribed. Nothing else. There is no name field and no profile.

It is double opt-in. Entering your address does not subscribe you: it sends one email with a confirmation link, valid for 48 hours, and only clicking that link puts you on the list. Until then, and if you never click, the row is a pending address and nothing is ever sent to it. We store a hash of the confirm token, never the token itself.

The legal basis is your consent, Article 6(1)(a) — the click on that confirmation link is the affirmative act, and it is the only thing that puts you on the list. We log the opt-in in our consent record (marketing_opt_in) so we can demonstrate it, as Article 7(1) requires, and we log the withdrawal (marketing_opt_out) the same way.

Withdrawing needs no account and no permission from us. Every issue carries an unsubscribe link. It is cryptographically signed and keyed to your address rather than tied to a login session, so it keeps working from an email years old, without you signing in, replying, or asking. Issues also carry the List-Unsubscribe headers, which put an unsubscribe button in Gmail's and Yahoo's own interface — one click, and it lands directly on us. Withdrawal is as easy as consent, which is what Article 7(3) requires and also simply how this ought to work.

The one place we deliberately add a step: the link in the body opens a page with a single confirm button rather than unsubscribing the instant it is fetched. That is not a dark pattern, it is the fix for one — mail scanners and link-safety checkers prefetch every URL in an inbox, and an unsubscribe that fires on fetch silently drops people who never clicked anything.

When you unsubscribe we keep the row rather than delete it, marked with the date and that it was user-initiated. That is deliberate: it is the proof we honoured your withdrawal, and deleting it would let a later signup form quietly add you back.

Consent records#

We keep a log proving what you agreed to and when — the event, which document, which version of it, how you agreed, the timestamp, your IP, and your user agent.

This exists because Article 7(1) GDPR requires a controller relying on consent to be able to demonstrate it. A record that you accepted version 1.0 of the terms on a given date, from a given address, is that demonstration. It is deliberately narrow: it proves an agreement happened; it does not track you.

Communications#

If you email support, sales, security, or the privacy address, we keep the correspondence so we can answer and follow up. Transactional email — verification, password reset, billing notices — is sent through Resend, which receives your email address and the message.

Post-deletion record#

When an account is deleted we keep a small record of it: the email address, the display name, the signup IP, the IP and user agent that requested the deletion, prior subscription details, and the deletion timestamp and reason. Section 5 explains why this is not us quietly keeping your account.

4. Why we use it, and our legal basis#

Where we rely on legitimate interests we have weighed our interest against your rights and concluded the processing is proportionate. Ask [email protected] if you want the reasoning for a specific one.

5. How long we keep it#

The 30-day post-deletion cooldown exists to stop the delete-and-resignup loop being a way to reset a free quota forever. It is the narrowest thing that works: it keeps an email address and a couple of IPs, not your account.

Billing records outlive account deletion because tax law says they must. We cannot delete an invoice on request, and neither can anyone else.

6. Who we share it with#

We do not sell personal data. We do not share it for anyone else's marketing.

We use service providers who process data on our behalf, under contract, on our instructions: hosting, authentication, database, payments, email, product analytics, error monitoring, rate limiting, edge delivery, signup validation, and IP geolocation. Each is listed — with what it receives and where it runs — in Subprocessors.

Analytics is the newest of those and the one worth naming here rather than leaving to a table: PostHog, processing on their EU cloud in Germany. They process only for us and only on our instructions. Sending events through a proxy on our own domain does not make them any less a processor of that data, and we are not going to pretend it does.

Beyond those, we disclose personal data only:

• When the law requires it, or a valid legal order compels it.
• To establish, exercise, or defend legal claims.
• To professional advisers under a duty of confidence.
• To a buyer, if the business is sold or merged — you would be told, and this policy would keep applying until you were told otherwise.

7. Job postings and the people named in them#

This is the interesting part, and we would rather answer it plainly than bury it.

Where the data comes from. We collect job postings from employers' own public career boards — the Greenhouse, Lever, Ashby, Workday or SmartRecruiters page a company publishes to advertise a role. These pages are published by companies, to the public, in order to be read. We mirror what is there.

Why it is mostly not personal data. A posting is company data: a role, a location, a salary band, a description. It is about a job, not a person.

Where personal data creeps in. Sometimes an employer writes a person into the posting — "report to Jane Smith, VP Engineering", a named hiring manager, a recruiter's contact email. We did not ask for it and we do not want it, but if the employer published it, our copy of the posting contains it. That makes us a controller of that incidental personal data.

Our legal basis is legitimate interests, Article 6(1)(f). Our interest is operating a dataset of published job postings for business use. The information was published deliberately, by the employer, on a public page, in a professional context, precisely so it would be read. The impact on the person named is low, and it is not information they would reasonably expect to be private — it was put on the open internet under a company's own name. We think that balance holds. If it does not hold for you, say so and we will act; see below.

What we do not do, and this is the important half:

• We do not build profiles of individuals.
• We do not enrich people. The enrichment we do — skills, seniority, salary, taxonomies — describes jobs, not the humans named in them.
• We do not sell, or offer, a way to look people up. There is no person search, no contact database, no "find the hiring manager" endpoint.
• We do not scrape candidates, CVs, or profiles. We take employers' job ads.
• We do not deliberately collect special-category data, and a posting that reveals any is not something we are seeking.

Transparency, and Article 14(5). We do not have a relationship with a person named in a posting and usually have no way to contact them without collecting more data about them than we hold. Article 14(5)(b) GDPR allows a controller to rely on public information of this kind in place of individual notice, which is what this section is for.

If you are named in a posting. You can ask us to remove it. Email [email protected] with a link to the posting or its job id and tell us which part is about you. We do not need you to prove a legal basis or make an argument; ask and we will remove it from the dataset. What we cannot do is take it off the employer's own board — we do not control that page, and if the posting is still live there, ask the employer too, or ours may reappear on a later crawl. Tell us and we will suppress the id so it does not.

Corrections and removals for data that is simply wrong go through Data corrections.

8. Your rights#

Under the GDPR you have the right to:

• Access — get a copy of your personal data and be told what we do with it.
• Rectification — have inaccurate data corrected and incomplete data completed.
• Erasure — have your data deleted, where one of the Article 17 grounds applies.
• Restriction — have us pause processing while something is disputed.
• Portability — get the data you gave us in a machine-readable format, and have it sent to another controller where technically feasible.
• Object — object to processing based on legitimate interests, including everything in this policy resting on Art. 6(1)(f). If you object we stop unless we can show compelling legitimate grounds that override your rights.
• Withdraw consent — where we rely on consent, withdraw it at any time, without affecting processing already carried out.

Exercising a right is free and we will answer within one month. If a request is complex we may extend that by two months and will tell you why. We may ask you to confirm your identity — not as an obstacle, but because handing your data to someone claiming to be you would be worse.

9. How to exercise them#

By emailing [email protected]. That is the route for all of them.

Some useful subject lines, which just route you faster:

• [email protected] — a copy of your data.
• [email protected] — delete the account.
• [email protected] — object under Art. 21.
• [email protected] — you are named in a posting.

Deleting your account walks through what deletion actually does, including what survives it and why — see section 5 on billing records and the deletion cooldown.

10. Automated decision-making#

We do not carry out automated decision-making that produces legal effects concerning you or similarly significantly affects you. Article 22 GDPR does not apply to our processing.

Specifically, and because this is the question we expect: the device fingerprint does not automatically block, throttle, restrict, or deny anything. It is stored for a human to look at if an abuse investigation happens. There is no score, no model, and no automatic action attached to it.

Quota and rate-limit enforcement is automated, but it is arithmetic against the plan you bought — not a decision about you as a person.

11. International transfers#

We are in Italy. Some of our providers process data outside the EEA, principally in the United States.

Where that happens we rely on the European Commission's Standard Contractual Clauses, or on an adequacy decision where one covers the provider — including the EU–US Data Privacy Framework for certified US providers — together with additional technical measures such as encryption in transit and at rest.

Subprocessors lists where each provider processes data. Several are configured to EU regions specifically, including our error monitoring and our product analytics — PostHog ingests to its EU cloud in Germany, so your analytics events are not a transfer at all.

To get a copy of the safeguards for a specific transfer, ask [email protected].

12. How we protect it#

• Passwords never reach us. Firebase Authentication holds credentials; our servers never see a password.
• API keys are stored as SHA-256 hashes, never in the clear. A database leak does not leak working keys.
• Session cookies are httpOnly, so page JavaScript cannot read them, and secure in production.
• CSRF protection on state-changing requests, using a double-submit token.
• A strict Content Security Policy, nonce-based on every page that renders your data, which blocks injected scripts even if HTML injection succeeded.
• Rate limiting on authentication endpoints, and account lockout after repeated failed sign-ins.
• Bot resistance via Firebase App Check with reCAPTCHA Enterprise, and edge filtering at Cloudflare.
• Breached-password checking at signup, using the Have I Been Pwned range API. This uses k-anonymity: only the first five characters of a SHA-1 hash of the password are sent, so your password — and enough of its hash to identify it — never leaves your browser. HIBP cannot learn your password, and is not a subprocessor.
• Error monitoring through Sentry, configured to its EU region.
• Encryption in transit everywhere, and at rest at our hosting and database providers.

No system is perfectly secure, and we will not claim ours is. If you find a vulnerability, tell [email protected]. If a breach ever puts your rights at risk, we will notify the Garante within 72 hours and tell you where the GDPR requires it.

13. Children#

The service is a business product for developers. It is not directed at children, we do not knowingly collect data from anyone under 16, and you must be 16 or older to hold an account. If you believe a child has given us data, tell [email protected] and we will delete it.

14. Cookies#

The portal's own cookies are all strictly necessary — session, CSRF, and the like — and those need no consent, because switching off the cookie that signs you in just means not being signed in.

There is a consent banner, and it asks about the two things that are genuinely your choice: product analytics in its identified mode (PostHog's ph_* cookie, a person profile, session replay) and the device fingerprint taken at signup for abuse prevention. Decline either and it does not happen. What declining does not stop — anonymous page counts that touch nothing on your device, and our own server-side record of what your account did — is set out in sections 3 and 4 above, and on the banner itself.

Cookie Policy lists every cookie, every localStorage key, and the reasoning for each.

15. Complaints#

Talk to us first — [email protected] — because we can usually fix it faster than anyone else can.

You also have the right to complain to a supervisory authority. Ours is the Garante per la protezione dei dati personali, the Italian data protection authority, at garanteprivacy.it. If you live or work in another EU or EEA country, you may instead complain to your own local supervisory authority.

16. Changes#

We will update this policy when what we do changes. Material changes get at least 30 days' notice by email or in the portal before they take effect. Every version carries a version number and a date, both at the top of this page.

We will not retroactively reduce your rights over data we already hold without asking you first.

17. Contact#