Privacy Statement

1. Information EnVenn handles

Depending on how EnVenn is used, the service handles:

• Account and access information: account email, authentication/session information handled through Supabase Auth, MFA factors, organisation membership, role, invitations and access records.
• Organisation configuration: organisation names and slugs, locations, rooms, event types, timezones, notification settings, public booking configuration, organisation links and sponsorship information.
• Booking information: booking title or reason, description, dates and times, room, event type, location, organiser details, primary contact name/email/phone, attendees and their email addresses, notes, calendar-invite choice, notification preferences, status and booking history.
• Microsoft connection information: Microsoft account and tenant identifiers, account email/display name, granted scopes, encrypted refresh tokens, connected calendar identifiers and names, owner email where available, and relevant calendar event data needed to import, synchronise or reconcile bookings.
• Billing information: the account email supplied to checkout when needed and Paddle customer, subscription, product, price, currency, billing-cycle, trial, period and status identifiers or metadata returned to EnVenn. EnVenn's application code does not collect or store raw payment-card numbers; Paddle's checkout handles payment methods.
• Notification records: recipient email or phone, message/subject or template content, delivery status, provider identifiers, errors, booking reference, notification type and timestamps where the relevant channel is used.
• Security and operational information: necessary cookies, request/correlation identifiers, support and audit records, provider webhook/job metadata, conflict records, redacted error diagnostics and hashed public-booking abuse/rate-limit subjects.

2. Public booking pages

A public booking visitor supplies their details directly to the organisation named on that booking page. EnVenn stores and processes those details so the organisation can assess or manage the booking, apply availability rules, create calendar events and send the communications the visitor or organisation has selected.

In live mode, EnVenn uses Cloudflare Turnstile to check public booking submissions. The server sends the Turnstile token, the trusted client IP address and a request idempotency value to Cloudflare for verification. For EnVenn's own public-booking rate limits, the client address, organisation page and SMS recipient (when relevant) are converted to keyed HMAC hashes before the rate-limit subjects are stored; the raw client IP is not stored in those EnVenn abuse-limit subject fields.

3. Why EnVenn uses this information

EnVenn uses information to:

• authenticate users and enforce organisation permissions and MFA;
• create, edit, cancel, import, display and audit bookings and booking history;
• calculate availability, apply booking rules, prevent overlaps and resolve synchronisation conflicts;
• connect and synchronise authorised Microsoft calendars and room mailboxes;
• send or record configured booking notifications and calendar invitations;
• operate subscriptions, trials and billing access through Paddle;
• prevent abuse, diagnose failures, secure the service and provide authorised support; and
• comply with legal obligations that apply to the operator.

4. Microsoft data and permissions

The standard Microsoft connection requests OAuth scopes for identity, profile, email, offline access, the signed-in user and read/write calendar access. Room discovery can request Microsoft Places access when that feature is used. EnVenn stores the refresh token encrypted with AES-256-GCM and retains the key version needed to decrypt it.

When EnVenn creates an organisation's own calendar copy, Microsoft can receive booking details required for that event, including configured title/body, room/location, organiser or contact information and human attendees where applicable. The paired organisation's private busy copy is deliberately reduced to shared-room/busy context and does not include the other organisation's detailed customer contact fields, notes or attendee list.

5. Service providers and disclosures

EnVenn discloses information to service providers only to operate the relevant feature or service. The current implementation uses:

• Supabase for authentication and PostgreSQL database infrastructure;
• Microsoft for connected calendar and account integration;
• Paddle for checkout, subscription administration and merchant-of-record billing;
• Resend for booking and operational email delivery;
• Netlify for application hosting/runtime;
• Cloudflare Turnstile for public-booking abuse and bot verification; and
• Sentry for production error monitoring under the configured conditions described below.

EnVenn may also disclose information when required by law or where reasonably necessary to investigate a credible security incident or protect legal rights, subject to applicable law.

SMS status: the current code does not transmit SMS message content or recipient phone numbers to a production SMS provider. It records the notification internally and uses a non-delivering console adapter. This statement must be updated before a real SMS provider is enabled.

6. Cookies and similar technical storage

EnVenn uses first-party cookies required for authentication and application state. The active-organisation cookie is HTTP-only, SameSite=Lax and has a 30-day maximum age. The temporary Microsoft OAuth state cookie is HTTP-only, SameSite=Lax and has a 10-minute maximum age. Secure cookies are used in production where configured by the application.

Third-party features such as Paddle checkout and Cloudflare Turnstile can also process browser/device information or use their own technical storage under their respective services and privacy terms.

7. Error monitoring and logs

Sentry is configured for actionable error monitoring rather than behavioural analytics: default PII sending is disabled, performance tracing is disabled by default, and EnVenn's Sentry scrubber removes request bodies and cookies, query strings, authentication/secret headers, common sensitive content fields and direct user email/IP/name fields before an event is sent. No scrubbing system can guarantee that an unforeseen error value will never contain personal information, so access to diagnostics should still be restricted.

The current application does not include an advertising platform or a behavioural-advertising tracker in the reviewed source.

8. How long information is kept

EnVenn uses scheduled database retention rules for many booking and operational records. Current configured periods include:

• live booking rows are generally retained until one calendar month after the booking end time; cancellation-pending bookings are held while provider deletion still needs resolution;
• superseded booking revision payloads are generally removed after 7 days, while minimised revision metadata can remain for up to 730 days;
• booking activity content is redacted after the booking is gone and redacted activity rows are deleted after 365 days;
• terminal SMS notification phone/content/error fields are redacted after 35 days and minimised rows are deleted after 365 days;
• completed or ignored Microsoft webhook raw content is removed after 14 days; certain failed raw webhook content can remain up to 30 days after work is exhausted, and minimised webhook receipts can remain 90 days;
• completed or permanently failed Microsoft sync-job raw payloads are removed after 30 days and completed job rows after 90 days;
• general audit events are retained for 365 days after their metadata is minimised, and platform support access events are retained for 365 days;
• processed Paddle webhook receipt records are generally retained for 180 days, with webhook error text cleared after 30 days; and
• operational events are generally retained 90 days and resolved incident records 180 days.

Organisation configuration, membership and active integration records can remain while the organisation/account or integration continues. Microsoft credentials are intended to remain only while the connection exists, subject to operational deletion/revocation handling.

Current exception: the newer booking email notification audit/idempotency table stores recipient email, subject, provider status/identifier and related metadata but does not yet have a timed retention purge in the current migrations. Those rows are deleted if the organisation is deleted because of their database relationship, but this statement does not claim a shorter automatic deletion period that the code does not currently enforce.

9. Security

Current controls include authenticated organisation access, database row-level security for ordinary user data paths, MFA requirements, transport encryption provided by the application and service providers, app-layer encryption of Microsoft refresh tokens, protected server-only secrets, restricted platform-support operations, audit trails and data minimisation/redaction jobs. These measures reduce risk but cannot guarantee absolute security.

10. Overseas processing

EnVenn uses global cloud providers. Personal information may therefore be processed or disclosed outside Australia depending on the actual production account configuration and the provider's infrastructure. The source repository does not establish every country used by the live Supabase, Microsoft, Paddle, Resend, Netlify, Cloudflare or Sentry accounts, so this statement does not invent a country list.

If the Australian Privacy Act 1988 (Cth) applies to the operator, the operator should confirm its real production provider locations and include likely overseas recipient countries where it is practicable to do so, as required by the Australian Privacy Principles.

11. Access, correction and deletion requests

Organisation users can update many current organisation and booking details through EnVenn according to their role. A public booking visitor should contact the organisation named on the booking page for routine corrections or requests concerning that organisation's use of their booking information.

There is no claim here that EnVenn currently provides a self-service account-deletion workflow. Requests to the EnVenn operator for access, correction or deletion should use the contact below. A deletion request may not remove information that must or may lawfully be kept, or minimised audit/security records that no longer contain the deleted booking content.

12. Australian privacy rights and complaints

Whether the Australian Privacy Act applies depends on the operator's circumstances; the repository does not establish its turnover or any other fact needed to decide that question. If the Privacy Act and the Australian Privacy Principles apply, you can ask for access or correction and complain about the operator's handling of personal information in accordance with those laws.

Send a privacy complaint to the contact below first. If the Privacy Act applies and the complaint is not resolved after giving the operator a reasonable opportunity to respond, you may have the right to complain to the Office of the Australian Information Commissioner.

13. Changes to this statement

This statement should be updated whenever EnVenn materially changes what personal information it collects, the providers it sends data to, or its retention practices. The current published version shows its last-updated date.

14. Contact

The legal operator configured for this deployment is EnVenn.

Email contact@envenn.app.

For service terms, see the Terms of Service.