Every third-party service below sits behind a configuration gate. With no credentials supplied, the platform runs on local, deterministic alternatives and no data leaves the deployment. A row applies to your workspace only if your provider has configured it. The four profile-sourcing and enrichment providers carry a second, independent gate that must be set on top of the credential, so an API key alone cannot start them.
The exception is hosting: the infrastructure the platform runs on receives everything it holds. For each row we say which vendor and region back it in each deployment. Our staging deployment runs on Google Cloud in Melbourne, Australia. Production does not exist yet, so where a vendor or a region has not been decided we say so rather than guess.
Application hosting — runs the platform, its background work and, in staging, the malware scanner. It processes everything the platform does while it runs.
Staging: Google Cloud Run, Melbourne. Production: to be decided.
Database hosting — the database and its backups: every record, with the email address and phone number on each candidate record encrypted by the platform; other copies of contact details, such as a candidate's sign-in account, are not.
Staging: Google Cloud SQL, Melbourne; backup location to be confirmed. Production: to be decided.
Secret storage — holds the credentials and the encryption keys the platform starts with. It holds no candidate records.
Staging: Google Secret Manager, Melbourne only. Production: to be decided.
Log collection — collects the platform's logs, which record identifiers and outcomes rather than content, and the hosting platform's own request logs, which include each visitor's IP address and browser.
Staging: Google Cloud Logging; log location to be confirmed. Production: to be decided.
Edge load balancing — terminates the encrypted connection for every request and passes it to the platform.
Staging: Google Cloud Load Balancing, a global service. Production: to be decided.
OpenAI — the AI provider for our production deployment: résumé parsing, applicant scoring, drafting, reply classification, search, the recruiter assistant, employer-facing candidate summaries, fit scoring of sourced profiles, and the text embeddings behind semantic matching and search. Receives CV text, messages, job descriptions, recruiter prompts and search text. Engaged only when an API key is configured; otherwise scoring and drafting run locally and no candidate text is sent anywhere. It will not process customer data in production until our review of it is complete.
Staging: when its key is configured; processing region to be confirmed. Production: OpenAI; processing region to be confirmed.
Anthropic — supported by the software for development only, and not used in production. Where it is configured in place of OpenAI it does the same work, except the embeddings, and receives the same kinds of data. Our production compliance check treats any Anthropic setting as engaging it, including a different address or extra request headers.
Staging: when its key is configured and OpenAI's is not; processing region to be confirmed. Production: not used.
Microsoft Azure OpenAI — supported by the software for development only, and not used in production: text embeddings for semantic matching and search. Receives candidate and job text through a projection that deliberately excludes name, employer and résumé summary, and a recruiter's search text as typed.
Staging: not configured by our staging deployment scripts. Production: not used.
Voyage AI — supported by the software for development only, and not used in production: the same embeddings, from the same text, when neither OpenAI nor Azure OpenAI is configured. With none of them, embeddings are computed locally.
Staging: when its key is configured and OpenAI's is not; processing region to be confirmed. Production: not used.
The scoring prompts leave out the candidate's name field, although the résumé summary they include can contain the name and contact details; the ranking of sourced profiles leaves out the profile's name field, although the scraped text it carries can contain one. Voluntary self-identification data is never provided to the model, and is structurally unreachable from the record it reads.
Twilio SendGrid — transactional email and recruiter outreach, including messages a recruiter sends from the inbox without a connected mailbox. Receives recipient name, email address, message content and attachments, and delivery events.
Staging: when its key is configured; processing region to be confirmed. Production: Twilio SendGrid, configured by our production deployment; processing region and contract to be confirmed.
Twilio — WhatsApp and SMS candidate messaging. Receives phone number, message content (a status update carries the candidate's first name and the job title) and delivery status. Requires a pilot enrolment and an explicit per-channel switch by the workspace owner, in addition to the credential; buying messaging credit also requires a paid entitlement.
Staging: not configured by our staging deployment scripts. Production: to be decided.
Each is authorised by an individual recruiter through that provider's own sign-in; access tokens are stored encrypted and are never written to logs. Nothing is synced until a recruiter connects their own account.
Google Workspace APIs (Drive, Gmail, Calendar) — CV import, inbound-email CV ingestion, mail sync, sending mail from the recruiter's mailbox, and interview calendar sync.
Staging: optional — engaged when our staging deployment stores an OAuth client for it; region to be confirmed. Production: to be decided.
Microsoft Graph (Outlook mail and calendar) — mail sync, inbound-email CV ingestion, sending mail from the recruiter's mailbox, and interview calendar sync.
Staging: optional — engaged when our staging deployment stores an OAuth client for it; region to be confirmed. Production: to be decided.
These process information about people who have not applied, so they carry the strictest gate on the platform: each requires both a credential and a separate confirmation that a data-processing agreement with that vendor is in place. With none configured, sourcing returns synthetic placeholder results and no real person's data is processed.
Apify — job-board and professional-profile sourcing.
Staging: not configured by our staging deployment scripts. Production: to be decided.
Bright Data — the same sourcing, when Apify is not configured.
Staging: not configured by our staging deployment scripts. Production: to be decided.
Enrichment provider — adds structured profile details (skills, education, social profiles) to a sourced profile.
No vendor is contracted. Staging: not configured by our staging deployment scripts; vendor and region to be decided. Production: to be decided.
Contact-reveal provider — looks up a sourced prospect's verified email address and phone number.
No vendor is contracted. Staging: not configured by our staging deployment scripts; vendor and region to be decided. Production: to be decided.
Sourced profiles that are never imported are automatically purged on a configurable schedule, and an erasure request reaches them independently of whether they were imported.
Google Cloud Storage (uploads) — storage for uploaded CVs, attachments and compliance documents, and for files awaiting a malware scan. Files are encrypted by the platform before they are written.
Staging: Melbourne. Production: Google Cloud Storage, configured by our production deployment; region and contract to be decided.
Google Cloud Storage (backups) — encrypted backups of each workspace, and the erasure ledger: internal identifiers and keyed digests of each erasure, consent withdrawal and opt-out, never the values, kept so a restore of the database can re-apply them.
Staging: Melbourne. Production: Google Cloud Storage, configured by our production deployment; region and contract to be decided.
Microsoft Azure Blob Storage (uploads) — the same file storage, as an alternative to Google Cloud Storage. Files are encrypted by the platform before they are written.
Staging: not used. Production: to be decided.
Microsoft Azure Blob Storage (backups) — encrypted backups and the erasure ledger, as an alternative to Google Cloud Storage.
Staging: not used. Production: to be decided.
Malware scanner — inspects every uploaded file before it is accepted. When it runs inside the deployment's own boundary it adds no third party beyond the hosting provider.
Staging: a self-hosted open-source scanner (ClamAV) on Google Cloud Run, Melbourne, which only the platform can call. Production: our production deployment configures a scanner endpoint; which scanner, and where, to be decided.
Stripe — subscription billing and hosted checkout. Receives billing contact and payment details. Stripe receives no candidate data.
Staging: test mode; processing region to be confirmed. Production: to be confirmed.
OpenTelemetry collector — receives a sample of request traces for diagnosing incidents: routes and paths, timings, status codes, browser type and database query text without its values, with access tokens, stored-file names and query values masked. Nothing is exported unless a collector is configured.
Staging: not configured by our staging deployment scripts. Production: collector vendor and region to be decided.
The operations directory's address is set once for the whole deployment, by us, so it is reviewed like any other third party before our production deployment uses it.
Operations directory — receives a hired candidate's identity and role details — name, email, phone, location, role and job title, skill tags, an identity fingerprint used to find an existing record, and the names of verified documents — when one-click recruitment-to-operations conversion is switched on.
Staging: not configured by our staging deployment scripts. Production: not configured; whether it is used, and where, to be decided.
These send data to a system the customer chooses and usually controls, so they are a disclosure to the customer rather than to a third party. They are listed because the data leaves this platform either way.
Webhook endpoints — signed notifications of the events a workspace subscribes to, sent to the public HTTPS addresses it registers.
Every change to this register is published in its Atom feed, which any feed reader can subscribe to. It is the channel our Data Processing Agreement names for notice of a new or replaced sub-processor.
30 September 2026 — SendGrid is used through two sending identities
No sub-processor was added or removed, and none moved. Twilio SendGrid is now used through two sending identities, each with its own API key: one for account-critical email (password resets, email confirmations, sign-in links and invitations) and one for recruiter outreach and the product's other email. SendGrid keeps its suppression lists for each identity separately, so a complaint about outreach no longer stops a password reset reaching the same address. The same information is sent to SendGrid as before. Our production deployment must hold both keys, and they must differ, before it starts.
29 September 2026 — What the log collection, Google and Microsoft rows say, corrected
No sub-processor was added or removed, and none moved. The log collection row said a last-line scrubber masks credentials and contact details in the application's logs; no scrubber runs over every log line. Each request's path is now logged with its capability tokens, stored-object names and contact details masked, and the production Google Cloud deployment leaves out of the platform's request logs a URL that carries a token, a code or an email address. The staging rows for the Google Workspace APIs and Microsoft Graph said our staging deployment does not configure them; it does, when an OAuth client for the provider is stored there.
29 September 2026 — The backup storage also holds the erasure ledger
No sub-processor was added or removed, and none moved. The backup storage rows, Google Cloud Storage and Azure Blob Storage, now also receive the erasure ledger: for each right-to-erasure request, consent withdrawal and opt-out, a record of internal identifiers and keyed digests of the email address, phone number and profile addresses involved, never the values themselves, kept so that a restore of the whole database can re-apply them before it serves anyone. It is written under its own prefix in the same storage as the backups, and kept for a period the deployment configures, which our production deployment must set before it starts.
28 September 2026 — What the AI, email and Microsoft rows say is sent, corrected
No sub-processor was added or removed, and none moved. The AI rows said sourced profiles are scored without the people's names; the profile's name field is left out, but the scraped headline and background text sent with it can still carry a name, and the résumé summary sent for applicant scoring can carry the candidate's name and contact details. Twilio SendGrid also carries the messages a recruiter sends from the inbox when no mailbox of their own is connected. Microsoft Graph, like Google, is used for inbound-email CV ingestion when that feature is switched on, and receives the email attachments imported as CVs.
27 September 2026 — Backups carry the stored files
A per-workspace backup now carries the stored files the workspace's records reference — résumés, email attachments and compliance documents — read from the file storage the deployment uses, so the backup storage rows receive that file content as well as the workspace's tables. Until now a backup carried stored files only where they sat on the application host's own disk, and none where they sat in cloud storage. A stored file that no record references is not copied.
26 September 2026 — Operations directory reclassified; every variable that engages Anthropic named; what production configures stated
The operations directory is set once per deployment by us rather than chosen by a customer, so it moves out of the destinations a customer chooses into its own section, and it needs the same review as any other sub-processor before our production deployment uses it; it also receives a hired candidate's job title, skill tags and an identity hash, which its row now lists. The Anthropic row names the variables the Anthropic software reads from its environment, including a different address and extra request headers, and our production compliance check counts any of them as engaging Anthropic. Google Cloud Storage is engaged by its quarantine bucket on its own as well as by its upload bucket. A WhatsApp or SMS status update carries the candidate's first name and the job title, and sending a messaging balance already paid for no longer needs the plan that bought it. Google and Microsoft also send mail from the recruiter's own mailbox. For email, file storage, backups and the malware scanner, the production column now says what our production deployment configures, with the regions and contracts still to be decided.
26 September 2026 — OpenAI added as the production AI provider; Anthropic, Voyage AI and Azure OpenAI withdrawn from production
OpenAI, through the OpenAI API, is added as the AI provider for our production deployment: résumé parsing, applicant scoring, drafting, reply classification, search, the recruiter assistant, employer-facing candidate summaries, fit scoring of sourced profiles, and the text embeddings behind semantic matching and search. It will not process customer data in production until our review of it is complete. Anthropic, Voyage AI and Azure OpenAI are withdrawn from production: the software still supports them for development, but a production deployment cannot use them. The embedding rows now also state that a recruiter's search text is sent to the embedding provider as typed, and that a résumé summary given to the scoring model can carry the candidate's name.
22 September 2026 — Register re-derived from the code; hosting, storage and telemetry added
Every row was re-derived from the application's composition, and the sub-processors the register had left out were added: the hosting services staging runs on (Google Cloud Run, Cloud SQL, Secret Manager, Cloud Logging and Cloud Load Balancing), Google Cloud Storage for uploaded files and for backups, Azure Blob Storage for backups, and an OpenTelemetry collector for exported traces. Twilio is engaged by its own Twilio configuration section, not the Messaging section this register named before. Each row now states which vendor and region back it in each deployment, and marks what has not been decided. Changes to this register are published as this feed from today.
25 August 2026 — Operations directory added to the published page
The operations directory, which receives a hired candidate's name, email, phone, location, role title and the names of verified documents when one-click recruitment-to-operations conversion is switched on, was in the register but missing from the published page. It is usually a system the customer already controls.
24 August 2026 — Register published
First publication of the sub-processor register, derived from the configuration gates that engage each third party.