The services behind HyperCRM

Active for every practice

These run wherever HyperCRM runs. They are not settings you switch on, and this section used to be shorter than the truth: email, bot protection and the in-app assistant were listed as opt-in, and none of them is.

• Neon — the PostgreSQL database, hosted in Frankfurt, Germany. This is where your practice data lives: patients, appointments, clinical notes, invoices and staff accounts.
• Vercel — hosting and compute for the application itself, in Frankfurt, Germany, and Vercel Blob for stored files. Patient documents, imaging and 3D scans are held in Blob's private storage and served only through short-lived signed links.
• Google (Firebase) — account authentication. Firebase verifies the identity behind each sign-in; it handles account identifiers such as email, not clinical records.
• Brevo — every email the product sends: sign-in links, staff invitations, appointment reminders, booking confirmations and requests, receipts and invoices with their PDF, closure notices, and messages from our contact form. Processes the recipient's address and the message body.
• Google (reCAPTCHA) — bot protection on public booking and form pages. Processes visitor interaction signals to tell a person from a script. It runs on our key, not on a setting in your practice.
• OpenAI — the in-app assistant. Processes what a member types to it, and the practice records it reads or writes in order to answer — which can include patient details, appointments, clinical notes and invoices. It is configured for the deployment, not per practice: where the key is absent the assistant does not appear at all, but that is our decision and not yours.

Active only when a practice uses the feature

These two features are the practice's own choice, and until it makes it, no data reaches the providers below.

• Twilio — SMS appointment reminders. Processes the recipient's phone number and the reminder text. Active only where SMS reminders are switched on. Twilio also places the one voice call that checks a practice's own phone number when it sets the phone assistant up.
• DIDWW — the phone assistant's telephone line. It carries the call itself, holds the practice's HyperCRM number, and for a practice bringing its own number it also holds the regulatory documents that number needs: the legal name, the registry and tax numbers, the address and the proof files. Releasing a line deletes those on our side; what DIDWW holds stays under its own retention.
• OpenAI — the phone assistant, which is a second and separate path from the in-app one above. The model hears the caller live, transcribes what they say, and writes the summary that is kept. A caller says what is wrong with them, so clinical content reaches it in the ordinary course of the feature working. The call is processed outside the EU until OpenAI EU data residency is in place for it.

This website, and not the product

One entry on this list has nothing to do with your patients. It is here because leaving it off would make the list incomplete, not because it touches clinical data.

• Google (Analytics via Tag Manager) — visitor analytics on hypercrm.app itself: which of our pages get read. It runs on this marketing website only. It is not present in the application, it never sees a patient, an appointment or a note, and nothing is set until a visitor accepts the cookie banner — before that the tag loads in a mode that stores nothing. Your practice's own website, generated by HyperCRM, carries analytics only if you add them yourself.

Active once your practice pays us

• Stripe — subscription billing. Processes your practice's billing contact details and its payment method, and issues your invoices. Card details are entered on Stripe's own payment page and are held by Stripe, not by us: we never receive a card number. What we do receive is a card fingerprint — an opaque token that identifies a card without revealing it — which our referral programme compares between referrals to catch a practice referring itself for the reward. The privacy policy sets out that use, its lawful basis and how long each signal is kept. Nothing reaches Stripe while a practice is on the free trial.

Not on this list: calendars your practitioners choose

HyperCRM can send each practitioner's appointments to their own calendar. They can connect their own Google account, or subscribe to a private link from any calendar app, such as Apple Calendar or Outlook. Each event carries the patient's name, the service, the time, the chair or room, and, for a practice with more than one location, that location's name and address, plus a link back into HyperCRM that opens only after sign-in. A booking request that the practice has not yet confirmed shows "Booking request" and the service, without the patient's name. Notes, phone numbers and email addresses are never sent.

The calendar provider that receives these events is not our sub-processor, so it has no row here. It does not work on our behalf. Each practitioner decides for themselves whether to use calendar sync, and chooses the provider under their own agreement with it. The practice owner can see in Settings → Team who has a calendar connected. Your practice remains the controller, and is responsible for telling its team when this is or is not appropriate. The Data Processing Agreement sets out what is sent, what we store, and how it is deleted.

What this page does not claim

This list is drawn from what the software actually connects to. The database and the application run in Frankfurt, Germany; the phone assistant is processed outside the EU until data residency is in place for it, and it says so in its own row. For the other providers this page does not assert a region, nor which certifications any provider holds — those are stated only where they are confirmed facts rather than assumptions. The security page covers how HyperCRM protects data inside its own boundaries; if you need something in writing for your own compliance, get in touch.

Every sub-processor