Subprocessors
The third-party providers that process data on our behalf, exactly what each one receives, and where it runs.
Version 1.0Last updated
This page lists every third party that processes personal data on our behalf, and what each one actually gets. It is referenced by the Privacy Policy, and it is meant to be read as the complete answer rather than a representative sample.
Each provider is bound by a data processing agreement, processes data only on our instructions, and is engaged only for the purpose in the table.
The list#
| Subprocessor | Purpose | Data | Location |
|---|---|---|---|
| Google Cloud Platform (Cloud Run, Artifact Registry) | Hosts the portal and its API routes | Anything in a request to the portal, transiently — IP address, headers, request bodies, application logs | United States (us-central1) |
| Google Firebase Authentication | Identity: sign-up, sign-in, sessions, password reset, email verification | Email address, password credential, Google profile basics (name, photo URL), auth tokens, sign-in metadata and IP | Google global infrastructure, primarily United States |
| Google reCAPTCHA Enterprise (via Firebase App Check) | Distinguishes real users from scripts on auth and signup | IP address, browser and device signals, interaction signals | Google global infrastructure, primarily United States |
| Neon | Managed PostgreSQL — all portal data (users, API key hashes, usage rollups, billing events, sessions, auth events, consent log) | Everything the Privacy Policy says we store about your account | Region configured on our Neon project |
| Stripe | Payments, subscriptions, invoicing, the customer portal, fraud prevention | Name, email, billing address, card details (held by Stripe — never by us), subscription and invoice history | United States and Ireland |
| Resend | Email delivery: transactional (verification, password reset, billing notices) and the newsletter, including its confirmation and unsubscribe links | Email address, name, message content | United States |
| Sentry | Error and performance monitoring | Error traces, request context, IP address, user id where an error is tied to an account | European Union (Germany) |
| PostHog | Product analytics, and session replay for visitors who consent to it | Events and page URLs, docs and help search queries, device and browser characteristics, referrer, an id for the browser, the session replay itself where consent was given, and your user id on events we can attribute to an account. Not your IP address — it is switched off in both modes and PostHog never receives it | PostHog EU cloud (Germany) |
| Upstash | Redis — distributed rate limiting and account lockout | IP address, account identifier, request counters | Region configured on our database |
| Cloudflare | Edge network, CDN, DNS, and security in front of the API and portal | IP address, request headers and metadata, country (cf-ipcountry) | Global edge network; US-headquartered |
| DeBounce | Validates that a signup email is not a disposable address | The email address entered at signup | United States |
| ip-api.com | Resolves a sign-in IP to an approximate city, region, and country for your dashboard's session list | IP address | Not specified by the provider; treated as a non-EEA transfer |
Locations describe where each provider processes data for us. Several operate global infrastructure rather than a single region. Transfers outside the EEA are covered by the Standard Contractual Clauses or an adequacy decision, as described in section 11 of the Privacy Policy.
PostHog runs behind our own domain — and is still a subprocessor#
Worth being precise about, because the setup invites a convenient misunderstanding and we would rather close it than benefit from it.
Analytics traffic does not go from your browser to a PostHog domain. It goes to
hyperjobs.io/ingest, our own origin, which reverse-proxies it onwards. The
reason is mundane: this is a developer product, a large share of the audience
runs an ad-blocker that blacklists analytics domains, and unproxied numbers would
be skewed towards the people least like our users.
What that changes is who your browser connects to. What it does not change is who processes the data. PostHog receives the events, stores them, and answers our questions about them, exactly as if your browser had called them directly. The proxy is a plumbing decision, not a privacy one, and anyone telling you a reverse proxy means the vendor is not involved is selling something. That is why PostHog is in the table above rather than in one of the sections below.
Two things it does mean, both real. Your IP address goes no further than the
infrastructure already listed above: the browser SDK is configured ip: false in
both of its modes, so PostHog never records it, and the events our backend sends
never had your IP in them to begin with — they come from our server, not your
device. And ingestion is on PostHog's EU cloud in Germany, so there is no
transfer question to answer here.
FingerprintJS is not a subprocessor#
We say this explicitly because it is exactly the assumption a careful reader would otherwise make — you see "fingerprinting" and reasonably conclude a fingerprinting company is involved.
It is not. We use the open-source FingerprintJS library. It is code that runs entirely inside your browser. It reads local browser characteristics, computes an identifier, and hands it to our page. No data is sent to FingerprintJS, their servers are not contacted, they receive nothing, and they process nothing for us.
This is a library, in the same sense that a date-formatting library is a library. There is no service behind it, no account, and no contract, because there is nothing to contract about. The identifier reaches our own server, and we hold it — see the Privacy Policy for what we do with it and why. Nobody else is in that path.
Have I Been Pwned is not a subprocessor either#
Same category, same reasoning. At signup we check whether a password appears in known breaches using the Have I Been Pwned range API. The check uses k-anonymity: your browser hashes the password with SHA-1 and sends only the first five characters of the hash. HIBP returns every known hash sharing that prefix, and the comparison happens locally.
HIBP never receives your password, your email address, or enough of the hash to identify the password. There is no personal data in the request, so there is no processing on our behalf.
Where the job dataset lives#
Worth stating plainly, because it changes the shape of this page.
The job postings dataset — the thing the API serves — does not live in the portal database. It lives in SQLite on the API VM. Neon holds portal data only: users, API key hashes, usage rollups, billing, sessions, auth events, consent records.
So none of the subprocessors above holds the dataset. Neon has never seen a job
posting. The two systems meet at exactly one point: the API validates your key
against the api_keys table and flushes per-key request counts back to it.
That also means a person named in a posting (see section 7 of the Privacy Policy) does not have their data spread across this list. It is in one place, and removal is one operation.
Changes to this list#
We will update this page before a new subprocessor starts processing personal data, or when one is removed or replaced.
If you want notice of changes in advance, email [email protected] and we will add you to the list of people we tell. If you object to a new subprocessor on reasonable data protection grounds, tell us — we would rather hear it than find out through a complaint.
Questions about any entry here, or a copy of the transfer safeguards for a specific provider: [email protected].