Privacy Policy.
What Repizen processes for account holders, and what it processes on behalf of customers when a visitor fills in an embedded form.
Effective date: [Effective date] · Last updated: [Last updated]
This document has not been reviewed by a lawyer.
It is an internal working draft prepared to structure a real privacy policy. It is not legal advice, it is not yet binding, and it must be reviewed and approved by qualified counsel in the relevant jurisdictions before it is published as Repizen's policy.
Every [bracketed value] below is a placeholder that a human must fill in or delete. Nothing here should be read as a claim that any certification, audit, or compliance status has been obtained.
1. Who we are
This policy is issued by [Legal entity name], registered at [Registered address] (“repizen”, “we”, “us”). Privacy questions go to [DPO / privacy contact email]. Where a representative or data protection officer is required, that is [DPO / representative details].
Repizen provides embeddable contact-form and meeting-scheduling widgets. Customers
paste a snippet into their own website; the widget is served from widget.repizen.com and
submitted data is processed by our API. That shape matters for privacy, because it means we handle personal
data in two very different roles.
2. Two kinds of people, two different roles
Read the row that describes you.
| Who | Example | Our role |
|---|---|---|
| Customers & account holders | You signed up at admin.repizen.com, configured an embed, or pay us | We are the controller. We decide what account data we need and why. Sections 3, 6, 7 and 10 apply. |
| Visitors who submit an embedded form | You filled in a contact form or booked a meeting on a company's website that happens to be powered by repizen | We are a processor acting on that company's instructions. They are the controller of your submission, not us. Section 4 applies, and Section 9 explains where to send requests. |
| Visitors to repizen.com | You are reading this page | We are the controller for basic site and log data. See Section 5. |
Put plainly: if you reached a repizen form on someone else's website, we did not choose to collect your data and we do not decide what happens to it. The website operator does. We store and transmit it for them, under contract, and we do not use it for our own purposes.
3. Data we process about customers (we are the controller)
- Identity and account data — name, work email, organisation, and the identifiers issued by our identity provider when you sign in to the console.
- Tenant and embed configuration — the forms and schedules you define, their field definitions, labels and validation rules, recipient routing, origin allowlists, custom domains, branding settings, sending-domain records, and publishable/administrative key metadata.
- Billing data — plan, entitlements, subscription status, invoices, and the billing identifiers our payment processor returns. We do not receive or store full card numbers.
- Support correspondence — what you send us when you ask for help, including the contents of a support form submission.
- Product and security telemetry — console and API request logs, IP address, user agent, timestamps, error traces, rate-limit and abuse signals.
4. Data we process on customers' behalf (we are the processor)
When a visitor uses an embed, we process — on the instructions of the customer who installed it:
- Form submission content — whatever fields that customer chose to collect. Typically a name, an email address and a message; because customers define their own fields, it can include anything they configure. Customers are responsible for not soliciting data they have no lawful basis to collect (see the Terms).
- Booking data — for scheduling embeds: the selected slot, attendee name and email, any notes, and the calendar invite generated from them.
- Recipient email addresses — the inbox a submission is routed to. Recipients are resolved server-side from an ID, so recipient addresses are never exposed in the customer's page source or to the visitor's browser.
- Delivery metadata — send status, timestamps, message IDs, bounce and failure information for the notification email and calendar invite.
- Technical and anti-abuse data — submitting IP address, user agent, the origin the request came from, honeypot and render-delay signals, and rate-limit counters. We process these to keep anonymous public endpoints from being abused as spam relays; this is a security necessity for the service, and is the one category we also treat as our own legitimate interest as a controller.
We do not sell this data, we do not use it for advertising, and we do not use it to train models. [Confirm and keep this commitment accurate before publishing]
4.1 How the embed loads (cross-origin by design)
The widget is served from widget.repizen.com, a different origin from the customer's website
— or from a customer-configured custom domain that points at us. Consequences worth stating plainly:
- Loading a page that contains an embed causes the visitor's browser to make a request to our host, which means we receive that request's IP address, user agent and referring origin even if the visitor never submits the form.
- Which sites may load or frame an embed is restricted per tenant by an origin allowlist and CSP
frame-ancestors. - The embed uses [cookies / localStorage — confirm exactly what the widget sets]. We do not use third-party advertising or cross-site tracking cookies in the widget.
- Where the customer's site requires a consent banner, the customer is responsible for obtaining consent before the embed loads. We cannot do that on their behalf.
5. repizen.com itself
This marketing site is static. It sets [cookies used on repizen.com — confirm; state “none” if none], and our hosting provider keeps standard access logs (IP, user agent, path, timestamp) for security and troubleshooting. Analytics: [Analytics provider or “none”].
6. Why we are allowed to process it
Where GDPR or a comparable regime applies:
- Performance of a contract — running the console, serving embeds, sending notification emails and calendar invites, billing.
- Legitimate interests — securing the service, preventing spam and abuse, debugging, and protecting our and our customers' deliverability reputation.
- Legal obligation — tax, accounting, and responding to lawful requests.
- Consent — where required, for example marketing email, and for embeds loading on sites that require prior consent (obtained by the customer).
For end-user submissions we do not determine the legal basis: the customer does, and warrants that they have one.
7. Who else touches the data
We use a small number of subprocessors. Named below are the ones we can state today; the remainder must be completed from the actual production inventory before publishing.
| Subprocessor | Purpose | Notes |
|---|---|---|
| Stripe | Payments and subscription billing | Card data is entered on Stripe's own checkout, not in our pages. We receive billing status and identifiers, not card numbers. |
Keycloak at auth.pnebula.com |
Identity and single sign-on for the admin console | Handles console authentication. Not used by the public embed endpoints. |
| [Subprocessor] | Email delivery / hosting / infrastructure | Complete from the production inventory. One row per provider, with location. |
| [Subprocessor] | [Purpose] | [Location] |
A current list, and how we notify customers of changes, will be maintained at [Subprocessor list URL].
8. International transfers
Data is processed in [Processing region(s)]. Where personal data leaves its region of origin, transfers rely on [Transfer mechanism — e.g. standard contractual clauses]. Customers who need a specific residency region should raise it before onboarding.
9. Your rights, and where to send a request
Subject to local law, you may request access, correction, deletion, restriction, portability, or object to certain processing.
- If you are a repizen customer or account holder — write to [DPO / privacy contact email]. We will verify your identity before acting.
- If you submitted a form on someone else's website — contact that website's operator. They are the controller and we act only on their instructions. If you cannot identify or reach them, write to [DPO / privacy contact email] and we will pass the request to the relevant customer.
We respond within [Statutory response window]. You may also complain to your local supervisory authority: [Supervisory authority].
10. How long we keep it
- Account and tenant configuration — for the life of the account, then [Retention period].
- Form submissions and bookings — [Retention period], or the retention window the customer configures, whichever is shorter. Customers can request deletion of their tenant's submissions at any time.
- Delivery and security logs — [Retention period].
- Billing and tax records — [Retention period], as required by law.
Backups are retained for [Backup retention period] and are overwritten on that cycle, so deletion may take that long to propagate.
11. Security
The service is designed with these controls, which ship on every plan: server-side recipient resolution so
an embed cannot be turned into an open mail relay, per-tenant origin allowlists and CSP
frame-ancestors, honeypot and render-delay bot traps, per-IP rate limits and request-size
caps, HTML-escaping of user-supplied values before they enter an email, DKIM-signed sending, and managed
identity rather than long-lived secrets in code.
This describes design intent, not a certification. We make no claim in this document to hold any audit, attestation, or certification — for example SOC 2 or ISO 27001 — and nothing here should be read as such a claim. [Compliance posture — legal and security to confirm what may be stated, and to add any certification only once actually held]
No system is perfectly secure. If we become aware of a breach affecting personal data, we will notify affected customers and, where required, regulators, within [Breach notification window].
12. Children
The service is not directed at children and we do not knowingly collect their data. Customers who deploy embeds on sites aimed at children are responsible for the additional consent requirements that brings.
13. Automated decision-making
We do not make automated decisions with legal effect about individuals. Automated processing is limited to spam and abuse scoring, which may cause a submission to be rejected.
14. Changes to this policy
We will post material changes here and update the effective date. Customers will additionally be notified at [Notification method] where the change is material.
15. Contact
[Legal entity name]
[Registered address]
Privacy: [DPO / privacy contact email]
General support: repizen.com/support
Security reports: [Security contact email]