Security
You are about to put your customer list -- the thing your business runs on -- into software built by someone you have not met. This page is what we can actually prove about how it is kept safe, and, just as importantly, what we do not have yet.
What we can prove
Each of these is enforced in the database or the code and checked by a test that runs before we release. Nothing is listed here on the strength of good intentions.
One business can never read another's data
Isolation is enforced by the database itself, not by application code. All 90 tables have row-level security switched on, and every request runs as the signed-in user, so the database refuses another organisation's rows even if our code asked for them.
We test that by attacking it, before every release
We keep a suite of deny-proofs that deliberately try to reach another organisation's data as a genuine logged-in user, and require every attempt to fail. They run alongside positive controls that prove ordinary access still works -- a test that only checks refusals would pass on a product that refuses everyone.
An account with no active membership sees nothing at all
The function that resolves which organisation you belong to is fail-closed: no active membership resolves to nothing, and there is no fallback to a default workspace. Revoking someone's access takes effect at the database, not just in the interface.
Switching a module off actually removes access to its data
Permissions are bound to your subscription at the database level, so an unsubscribed module's data cannot be read through the app or the API. Nothing is deleted when it switches off -- the records stay exactly as they were and return if you subscribe again.
Your WhatsApp credentials cannot be read by any login, including yours
They live in a table with no read access granted to any customer account at all -- only the server itself. That restriction is one of the properties the deny-proofs check on every run.
We verify that WhatsApp messages really came from Meta
Every incoming webhook is checked against a cryptographic signature before it is read, using a constant-time comparison. An unsigned or wrongly-signed request is rejected outright, which we test by sending one.
We do not store the IP addresses of people who fill in your forms
Our public forms and signup need to tell one submitter from another to stop abuse, so they store a one-way hash instead of an address. We cannot reverse it, and two different forms cannot be joined on it.
Your audit trail cannot be edited or erased by anyone using the app
Customer accounts can read audit records and nothing else -- no insert, update, delete, or bulk-empty. Only the server writes them.
You can take your data out, and have a person's record removed
One action exports everything your workspace holds as a single file. A separate tool finds everything held about one person, hands them a copy, or erases it -- and states plainly what it will not erase, such as tax invoices GST law requires be kept.
We only tell you what we actually know about a message
A WhatsApp message shows as delivered or read only when Meta reports it. We never infer or upgrade a status, so if read receipts are off on the recipient's phone we will never show 'read' -- because we genuinely do not know.
The AI assistant runs as you, and every number it says is computed by us, not by it
The assistant reads only what your own login can read -- the same row-level rules as every screen, never a privileged path. Figures come from the same deterministic code that renders your dashboards; the language model only words them. A deny-proof attacks this on every run: another organisation's data, a teammate's numbers you lack rights to see, and prompt-injection attempts planted in record names all have to come back empty.
You can switch the AI assistant off for your whole workspace, instantly
One setting, held in your workspace's own row. When it is off, the request is refused before any of your data is read -- nothing reaches the AI provider at all. The deny-proof flips the switch and asserts exactly that refusal.
We name the AI provider and hold it to a written data agreement
Assistant language processing runs on Groq (GroqCloud). Their Data Processing Addendum restricts processing of customer data to providing the service and commits to deletion within 180 days of termination; we link it rather than paraphrase beyond it, and we send only the minimum the answer needs. Saahak itself never uses your data to train any model.
What we do not have
Saahak is early. If your procurement process requires any of the following, we do not meet it yet -- and we would rather you learn that here than after signing.
- · No SOC 2 or ISO 27001 certification.
- · No third-party penetration test yet.
- · No published uptime commitment. There is a status page, but no promised number behind it.
- · No bug bounty programme.
Where your data lives
The application runs in Mumbai on Vercel, and the database is hosted by Supabase. WhatsApp messages are delivered by Meta from your own business number -- Saahak is the pipe, and Meta bills your business directly. Data is encrypted in transit and at rest, and passwords are hashed -- never stored in a form anyone can read, including us.
The full list of services that touch data on our behalf: Supabase (database and sign-in), Vercel (hosting), Meta (WhatsApp delivery, when you use it), Razorpay (subscription payments), Resend (transactional email), Groq (the AI assistant, with its own switch), and PostHog (product analytics -- how the app is used, never your customers' contact data). Each appears with its role and processing terms in our privacy policy.
Telling us about a problem
If you find a security issue, email ayush@capeasy.in with enough detail to reproduce it. We will confirm we received it, and we will not take any action against anyone who reports something in good faith.
This page describes the product as it stands today and changes when the product does. If something here turns out to be wrong, that is a bug and we want to hear about it.