Draft for legal review

Privacy Policy

Version 2026-05-11 · Effective 2026-05-11 · Material version

1. Who this notice is from and who it covers

This Privacy Policy explains how Amarantic (we, us, our) processes personal data. We are based in Copenhagen, Denmark. The legal entity, registered office, and CVR number that should appear in this section are pending confirmation by our lawyer and will be inserted before production rollout.

This notice covers three audiences:

Public visitors to amarantic.com who land on a marketing or legal page.
Tenant Owners and staff of professional service businesses that subscribe to Amarantic.
End-clients of those Tenants — the people who book appointments, register an account on a Tenant's booking page, or receive communications through Amarantic.

If you are an end-client and you have a question about how your data is processed by a specific Tenant, the Tenant is the controller of that data and should be contacted first. We will assist them within the limits of our processor role.

2. Roles under GDPR

Personal data	Role of the Tenant	Role of Amarantic
End-client booking and CRM data	Controller (Art. 4(7))	Processor (Art. 4(8))
End-client special-category data (e.g. health notes)	Controller, with end-client explicit consent (Art. 9(2)(a))	Processor with encryption at rest and consent-gated egress
Tenant Owner / staff account data (auth identity, billing contact)	—	Controller
Platform marketing addressed to Amarantic prospects	—	Controller
Marketing the Tenant sends to its own end-clients	Controller	Processor + suppression infrastructure

The split is restated in detail in the Data Processing Agreement (opens in new tab).

3. What we process

3.1 Visitor data on `amarantic.com`

We use essential cookies only today. The marketing site carries no analytics SDK, no marketing pixels, and no third-party trackers. The Layer-3 footer notice on every public page reminds visitors of this and links to this Privacy Policy.

3.2 Tenant account data

When you sign up at app.amarantic.com/signup and complete subscription checkout, we process:

your authentication identity (email, hashed password, OAuth identifiers if used) via Supabase Auth;
your tenant profile fields (business display name, physical address, business phone, mobility flag, team size, offerings) captured during onboarding;
billing information through Stripe (we do not store full card numbers; Stripe is the controller of card data and our processor for the subscription side);
platform-marketing consent (a separate platform-level table, not mixed with tenant-side consent).

3.3 End-client data captured through Tenants

Through your Tenant's booking, intake, treatment, and marketing flows we may process, on the Tenant's behalf:

contact details (name, phone, optionally email);
booking history, services, prices, payment records;
client notes (general preferences);
special-category data (allergies, skin conditions, treatment notes) — only where the Tenant has configured the surface and the end-client has granted explicit consent under Art. 9(2)(a);
consent records and consent withdrawals;
limited derived insights (visit frequency, churn-risk segment, predicted next-visit date) for the Tenant's own analytics;
audit records of AI-assisted actions taken by Tenant staff.

We do not collect date of birth, gender, home address, social-media handles, photos of end-clients, or biometric data as a default. The Tenant may add only fields that match the documented Legal Basis Mapping in our internal compliance specification.

4. Lawful bases (Art. 6 / Art. 9)

Data category	Legal basis	GDPR reference
End-client name, phone, email	Contractual necessity	Art. 6(1)(b)
Booking date / time / service / staff	Contractual necessity	Art. 6(1)(b)
Appointment reminders (booking confirmations, reschedule notifications, day-of reminders)	Contractual necessity	Art. 6(1)(b)
Payment transaction records	Legal obligation (bogføringsloven, 5-year retention)	Art. 6(1)(c)
Staff schedules and working hours	Legitimate interest	Art. 6(1)(f)
Marketing emails and SMS to end-clients	End-client consent	Art. 6(1)(a)
Analytics cookies on the Tenant booking portal	End-client consent	Art. 6(1)(a) + ePrivacy
General client notes	Contractual necessity	Art. 6(1)(b)
Health notes / clinical notes	Explicit end-client consent	Art. 9(2)(a)
AI-derived insights (visit frequency, churn risk, predicted next visit)	Legitimate interest, internal only	Art. 6(1)(f)
AI-driven outreach (rebooking emails, churn intervention, slot-fill offers)	Consent or legitimate interest with Art. 22 safeguards	Art. 6(1)(a) / 6(1)(f) + Art. 22
IP addresses in security logs	Legitimate interest (anonymized after 90 days)	Art. 6(1)(f)
Tenant profile fields used to render the booking page and invoices	Contractual necessity	Art. 6(1)(b)
Platform marketing consent for Tenant Owners	Tenant Owner consent	Art. 6(1)(a)

The appointment-reminders row is important: a confirmation or reminder of a booked appointment fulfils the booking contract the end-client made with the Tenant and does not require a separate consent record. Promotional marketing is different and requires the optional Marketing consent captured at booking.

5. The simplified booking-widget consent model

When a Tenant publishes a booking page, the end-client sees exactly two checkboxes at booking time:

Required — a single combined acknowledgement covering Terms of Service (opens in new tab), Privacy (opens in new tab), data-usage, and AI-as-product disclosure. The copy uses acknowledgement language; the checkbox blocks submission until ticked. Underlying record: one row in our tenant-scoped consent ledger with consent_type = "terms_of_service" as the canonical anchor.
Optional — a single Marketing consent checkbox. Never required. Never blocks submission. The copy uses consent language and explicitly states that the end-client can withdraw at any time. Underlying record: one row with consent_type = "marketing_email".

No SMS-reminders checkbox is shown to end-clients; reminders run under Art. 6(1)(b). A health-data acknowledgement is shown only when the Tenant has configured a sensitive intake field that requires it.

6. Marketing-consent withdrawal (Art. 7(3))

We treat withdrawal of marketing consent as having to be as easy as giving it. End-clients can withdraw in three ways, all of which write append-only records:

click the unsubscribe link in any marketing email — the click records a new consent row with granted = false and adds the recipient to the suppression list;
toggle marketing consent off in their client-side preferences if the Tenant has exposed the portal preferences UI;
ask the Tenant's staff to record a withdrawal on their behalf (phone, in person, message) — staff use a dedicated affordance and the audit log captures who recorded it.

Suppression is checked at send time, regardless of audience selection. A Tenant's marketing system cannot deliver to a recipient whose latest record is a withdrawal.

7. Where data is stored

Sub-processor	Purpose	Location	Transfer mechanism
Supabase Inc.	Database, authentication	EU (Frankfurt, `aws-eu-central-1`)	N/A (EU-to-EU)
Vercel Inc.	Application hosting, edge network	EU (Stockholm) + global edge POPs	SCCs for non-EEA edge POPs
Upstash Inc.	Redis cache, rate limiting	EU (Frankfurt)	N/A (EU-to-EU)
Stripe Payments Europe Ltd.	Subscription billing, payment processing	EU/global	Article 46 transfer tools where applicable
Resend Inc.	Outbound transactional email (current)	US	SCCs / EU-US Data Privacy Framework
GatewayAPI ApS	SMS delivery	Denmark	N/A (EU-to-EU)
Anthropic PBC	LLM inference, AI assistant	US	SCCs
OpenAI L.L.C.	LLM inference fallback	US (EU residency available)	SCCs
Twilio Inc.	SMS for time-sensitive slot offers (where enabled)	US	SCCs

The full and current list — including the function-not-vendor framing and the conditional Standard Contractual Clauses clause — is at Sub-processors (opens in new tab). We are working to replace Resend with Mailjet (operated from France, in the Sinch Email group) as part of an EU-first email provider transition. The transition is in progress; details are on the Sub-processors page (opens in new tab) so you can see honestly which provider is in use.

8. Retention

Data	Retention
Active end-client records	Duration of Tenant subscription
Booking financial records (PII anonymized, amounts kept)	5 years from booking date (bogføringsloven)
Subscription invoices	5 years from issue date (bogføringsloven)
General client notes	Duration of subscription, then hard delete
Health / clinical notes (encrypted at rest)	Duration of subscription, then hard delete and key wipe
Consent records	5 years after withdrawal, then hard delete
Audit logs (general + AI)	3 years
IP addresses in logs	90 days, then anonymized
Cancelled Tenant data	90 days post-cancellation, then hard delete
Tracking-link click records (salted SHA-256 of IP/UA)	5 years
Pre-payment onboarding drafts	30 days from creation

A daily retention job (02:00 UTC) enforces the table above automatically and is logged to a separate retention ledger.

9. Data subject rights

End-clients of a Tenant have, against that Tenant as controller, the following rights:

Access (Art. 15) — a copy of personal data the Tenant holds about them;
Rectification (Art. 16) — correction of inaccurate data;
Erasure (Art. 17) — deletion subject to legal-retention exceptions (see Section 8);
Restriction (Art. 18) and Objection (Art. 21) — including objection to direct marketing and objection to processing based on legitimate interests;
Portability (Art. 20) — a machine-readable export including AI-derived insights and agent decisions;
Withdrawal of consent (Art. 7(3)) — see Section 6 for the three withdrawal paths.

We support the Tenant in fulfilling these requests. Our internal erasure cascade hard-deletes or anonymizes data across every relevant table, including encrypted clinical notes and per-mutation change-logs, within one tenant-scoped transaction. The erasure operation returns a summary so the Tenant can confirm what was erased and what was retained under a legal-retention exception. The detailed cascade is described in the DPA (opens in new tab).

For data we control directly — Tenant Owner authentication identity, platform-marketing consent, billing contact — please contact us at privacy@amarantic.com.

10. AI processing

We use AI to help Tenants run their business: surface candidates for slot-fill, prepare draft messages, navigate the product, generate non-sensitive insights. The disclosure shape and the current named vendors are on the Sub-processors page (opens in new tab).

Key guarantees:

end-clients of a Tenant can opt out of AI-driven actions via the ai_processing consent type; the Tenant's outreach pipeline checks this consent before every action;
no fully automated decision with legal or similarly significant effect is made about an end-client by AI alone (Art. 22). Significant or customer-affecting actions remain operator-approved;
AI prompts use the minimum data needed; Art. 9 special-category content is never sent to an LLM sub-processor without an end-client's explicit consent under the narrowed Art. 9 egress gate;
AI memory is per-request by default; durable Amarantic memory is not enabled in v1 and any future durable memory will land with its own privacy review.

A test-only Google Gemini path exists in code for benchmarking; it is not a production sub-processor of Tenant data, and it is not listed at Sub-processors (opens in new tab) for that reason.

11. International transfers

Where a sub-processor is established outside the EEA, the transfer is governed by Module-2 Standard Contractual Clauses (Commission Decision 2021/914) or another Article 46 transfer tool (e.g. EU-US Data Privacy Framework adequacy for eligible US sub-processors). We maintain Transfer Impact Assessments for each US sub-processor we use today.

We do not claim "all data stays in the EU" while any non-EEA sub-processor is on the Sub-processors (opens in new tab) list. The conditional SCCs clause and the public-copy guardrail described there are load-bearing.

12. Cookies

The marketing site (amarantic.com) uses essential cookies only today and carries no analytics SDK. The Layer-3 footer notice on every public page reflects this. If we add non-essential cookies in the future, we will replace the static notice with a real consent banner before any non-essential cookie fires.

Inside the product (app.amarantic.com), we use session cookies that are essential to authenticate you, plus a short-lived (30 minutes) HMAC-signed attribution cookie used by trackable booking links — the cookie carries no PII, is HttpOnly + Secure + SameSite=Lax, and can be disabled per-Tenant.

13. Security

Our Art. 32 measures are summarized in the Terms (opens in new tab) (Section 9) and in the DPA (opens in new tab). Highlights: PostgreSQL Row-Level Security on every tenant table; AES-256-GCM field-level encryption for Art. 9 fields; append-only audit ledgers; rate limiting; session-cookie authentication.

14. Personal-data breach

We notify affected Tenants of a personal-data breach within 24 hours of confirmed awareness so that they can fulfil their own Art. 33 obligation. We notify Datatilsynet (opens in new tab) (the Danish Data Protection Authority) within 72 hours where the breach is reportable. We notify affected end-clients without undue delay where the breach is likely to result in a high risk to their rights and freedoms (Art. 34).

15. Contact and supervisory authority

Privacy contact — privacy@amarantic.com
General contact — support@amarantic.com
Supervisory authority — Datatilsynet (opens in new tab), Carl Jacobsens Vej 35, 2500 Valby, Denmark · dt@datatilsynet.dk (opens in new tab) · www.datatilsynet.dk (opens in new tab)

End-clients have the right to lodge a complaint with Datatilsynet (opens in new tab) or with the supervisory authority of their habitual residence or place of work.

16. Changes to this Privacy Policy

We version this policy in the same way we version all of Layer 1. The current version and effectiveAt appear above. Material changes (material: true) trigger re-acknowledgement when you next take a privileged action inside the Account; non-material changes surface as a passive notice. Past versions are preserved.