Security
We are asking for a key to your pipeline. Here is how we hold it.
An ATS API key can read every candidate in your account and change their records. Anything short of a serious answer about how that key is stored should disqualify a tool like this one.
Credentials
The key never reaches the phone.
When you connect a source, the credential is written into an encrypted vault in our database. It is not stored on the device, not held in the app's local storage, and not compiled into the app bundle.
Retrieving the plaintext is possible in exactly one way: a database function that first checks you own the connection, called from the server function that is about to make the request, running under your own authenticated session. The value is used for that call and discarded.
Delete a connection and a database trigger purges the encrypted secret in the same transaction. There is no orphaned copy left behind.
Network
The app never calls your ATS.
Every outbound request to your ATS is made by a server function, not by the app. The phone asks us for candidates; we ask your ATS. That single choice is what allows the credential to stay off the device, and it puts rate limiting, retries, and logging in one place instead of thirteen.
It also means a lost or compromised phone cannot be used to reach your pipeline: sign the device out and its access is gone with the session.
Isolation
Enforced in the database, tested on every commit.
Every table has row-level security enabled and is scoped to its owner. There is no table in the system that is readable without a policy check, and no "trust the client" path around it.
Cross-account isolation is not an assumption we make — it is a test suite. On every commit our continuous integration spins up a real database, creates two accounts, and asserts that the second cannot read or write anything belonging to the first, across every user-scoped table.
When you share a connection with a teammate, they gain the ability to read that connection's requisitions and candidates and to swipe on them. They do not gain the credential — decryption still checks ownership, and sharing is not ownership.
Data
What we keep, and why.
Cached candidates and requisitions. Pulled from your ATS so a deck does not re-fetch on every card. Your ATS remains the record of truth; this is a cache and is treated as one.
Your swipes and grades. Which candidate, which direction, what each configured action returned. This is the log that lets you see what actually landed.
Your account. Email, display name, organisation name, notification and interface preferences.
Device push tokens. Only if you turn notifications on, and only to send you alerts about your own requisitions.
We do not sell data, we do not build a cross-customer candidate database, and we do not train anything on your pipeline.
Subprocessors
Who else touches it.
Supabase
USDatabase, authentication, and the server functions that call your ATS
Stripe
USSubscription billing. Card details go to Stripe directly and never reach us
Expo
USPush notification delivery to your device
Resend
USTransactional and enquiry email
Reporting
Found something?
Email security@recruiterswipe.com with what you found and how to reproduce it. We will acknowledge within two working days and keep you updated until it is closed.
Please do not test against another customer's account or run automated scanning that would degrade the service. Everything else is fair game and we would rather hear it from you than from an incident.