How Bookingwell is protected

1Signing in

There is no password. To sign in, an owner asks for a link and Bookingwell emails a single-use one that lives for fifteen minutes. This is deliberate: a solo owner tends to reuse a password everywhere, and removing the password removes the whole problem of a stolen or guessed one.

The link is 256 bits of randomness, only a fingerprint of it is stored rather than the link itself, and it can be used exactly once, claimed by a single database operation so two clicks cannot both succeed. Asking for a link never reveals whether an address has an account, and the request is rate limited. The session that follows is a signed, http-only cookie that lasts twelve hours.

2Encryption

Everything is served over HTTPS, and every outbound connection the product makes is encrypted. The database and every uploaded file are encrypted where they are stored, by Cloudflare, with keys Cloudflare holds.

That protects a disk. It does not protect one sensitive column from anyone who can read the database, so the credentials that would open a business's connected Google account get a second, stronger layer. Each is sealed with modern authenticated encryption (AES-256-GCM) under a key that lives outside the database entirely, in a platform secret the running software can use and a copy of the database cannot. A stolen copy of the database yields those credentials as unreadable ciphertext and no key. Sign-in links and API keys are stored only as one-way fingerprints, so a copy of those tables is not a set of working credentials either.

Stated plainly: what a stolen database would still expose is customers' names, emails, phone numbers, addresses and their appointments and receipts. What it would not expose is any connected Google account, any Stripe credential, any working sign-in link, or a card number.

3Keeping businesses apart

Many businesses share one database, and this is the strongest part of the product. Every record carries the identity of the business it belongs to, one and only one part of the code is allowed to reach the database, and an automated check fails the build if any query could read across businesses. A separate test stands up two businesses and proves they cannot see or collide with each other, including that deleting one leaves the other untouched. An API key is bound to exactly one business and cannot reach another's data. Uploaded files are constrained the same way, so a business's logo and photos live under its own space and nothing else can point at them.

4The records we refuse to hold

Bookingwell holds appointments, contact details, consent answers and receipts. It does not hold clinical notes or any record of what happened in an appointment, and this is enforced by a rule in the database itself, not by a policy someone has to remember. When a business keeps such a document, it is written to the business's own Google Drive and Bookingwell keeps only a link and a fingerprint. The permission the product asks of Google reaches only the files the product itself created, so it cannot read anything else in the business's Drive.

For a counsellor, whose most sensitive record is exactly the note that never enters our system, this means the buying decision does not turn on trusting us with it, and a breach of our database cannot expose it. That is real, and it is the reason the design exists.

5Payments

No card data reaches Bookingwell. A customer paying is sent to Stripe's own hosted page, and Bookingwell stores only the identifier of the business's Stripe account and the amounts, never a number or a token that could move money on its own. Payment notifications from Stripe are verified against a signature before they are acted on, and each is recorded once so a repeated notification cannot double a refund.

6Backups

The backup process does something most do not: after taking a backup it immediately restores it into a scratch database and refuses to trust it until the restored copy answers real questions about its contents. A backup that does not restore is set aside rather than counted. The most recent fourteen are kept.

The honest limit is that backups currently live on a single encrypted machine, with no second copy kept elsewhere yet. This defends against the likely failures, a bad change or an accidental deletion, and not against that machine being lost. Moving a copy offsite is planned work, and the connected-Google credentials in a backup are ciphertext, as above, not working keys.

7Deletion and export

A business can export everything Bookingwell holds about one person, or about the whole business, and can erase a person's details or close the account entirely, files included. Closing an account leaves behind one record proving the deletion happened, carrying counts and no personal detail. A nightly job clears the short-lived data on the published schedule in the privacy page.

8Who at Synura can see your data

Told plainly, because you should not have to discover it. A business owner signed into Bookingwell only ever sees their own business, and a sign-in can never cross from one business to another. But anyone at Synura with access to our Cloudflare account can, in principle, read the database directly, the same way any hosting account holder can. We keep that access to the people who run the platform. It is not something a business can revoke on its own today, and we would rather say so than let a review find it.

A record of consequential actions (a booking created, moved or cancelled, a note changed, a sign-in, a key issued, a payment) is kept for two years and always records who did it. It carries no personal detail. It is a record we keep by convention in the code rather than one sealed against every possible tampering, which is honest to state and adequate for the disputes it exists to settle.

9What is not done yet

So that nothing here reads as a claim by omission:

• A second sign-in factor is being added and is not yet in force on every account.
• Backups are kept on one machine, with an offsite copy still to come.
• Bookingwell is not yet sold to health-information custodians such as physiotherapy clinics under Alberta's Health Information Act. That path, and the agreements it requires, are coming, and until they are in place we do not take those clients and do not claim that Act.
• Synura does not hold a SOC 2 report of its own. The hosting, payment and email providers hold their own certifications, listed on the privacy page.

For what is collected and how long it is kept, see the privacy page. For any security question, or to report something, write to hello@synura.ai.