Security

• Accounts, appointments and records are stored in a managed PostgreSQL database (Supabase). The hosting provider encrypts the data at rest; every connection between the apps, this website and the database uses TLS (https).
• This website is served over https only. Section 10 of the Privacy Policy says in which country the data is hosted and under which guarantees.

Access rules are enforced in the database itself (row-level security), not only in the apps, so a bug in a screen cannot show you someone else's data:

• A patient sees their own appointments, records and reviews.
• A professional sees the patients who booked with them: their name and contact details stay in the professional's client list, while health data is visible only during the appointment window or through a share the patient granted. Only approved professionals can take bookings.
• A staff member (assistant, receptionist, manager) acts only for the doctors they work for: the account is created by a doctor or their clinic manager, and the same person can work for several doctors, each one inviting them. Revenue and invoices stay hidden from staff unless the doctor grants it per person.
• Health data (health profile, consultation notes, issued prescriptions and certificates) is never read directly: it goes through controlled server functions, and every access to the health profile and consultation notes by a professional is logged in a journal the patient can consult.
• Calendify's administrators manage accounts and approvals; they cannot open medical files.

• Documents a patient uploads, and prescriptions or certificates a doctor issues, are kept in a private storage area. They are never reachable by a public link: each opening uses a short-lived signed link, created only for the owner or a doctor the patient shares with.
• Sharing is the patient's decision: all records or selected ones, with a doctor they choose, revocable at any time.
• A prescription or certificate carries a QR code. Anyone can check that the document is genuine and unaltered on this website; the content itself appears only after a six-character code printed on the document. Checks are rate-limited per address and locked after ten wrong codes, and those pages are never cached or indexed.

• Passwords are stored as salted hashes by the authentication service; nobody at Calendify can read them.
• Two-step sign-in: optional and available to every account. Once you turn it on in your account settings, a code sent by e-mail or SMS is asked at each sign-in. Sending is limited (one code every 30 seconds, five per hour, each valid ten minutes for five attempts).
• Turning two-step off, changing its method, or changing the e-mail address or phone number of an account requires a fresh code, so a stolen session cannot take the account over.
• Role, activation and approval fields are guarded in the database: an app cannot grant itself rights.
• On the phone, you can sign in with Face ID or your fingerprint instead of typing your password (optional).

Patients never pay through Calendify: the service is free for them. Professionals are invoiced by Calendify; no card number is entered on Calendify's own pages.

• No script from another company runs on this website: no advertising, no third-party analytics (see the Cookies page).
• Signing in keeps no session here. The session is handed to the clinic application in the address fragment (after #), which browsers never send to servers or logs.
• Document verification pages are served with no-store, no-referrer and noindex headers and cannot be embedded in another site.

• Photos of an identity card taken for a walk-in identity check are deleted automatically once the check is settled.
• You can delete your account from the app or by e-mail; what is erased and what the law requires us to keep is listed on the Delete your account page.

If you believe you have found a vulnerability or a data exposure, write to security@calendify.ma with the steps to reproduce it. We read every report and aim to reply within one business day, and ask you not to access or keep data that is not yours while testing.