Private audit access and platform security

A private workspace for each agency

The workspace requires authentication and checks the operator’s assigned permissions. Browser sessions use HttpOnly cookies, limited lifetimes, and server-side session checks. Requests that change campaign data, approvals, invitations, or appointments also require request-origin and anti-forgery checks.

Each agency has its own workspace. Owner, administrator, operator and viewer permissions control what each team member can do. Workspace boundaries are checked by the application and enforced through PostgreSQL row-level policies and relationships between records. Selecting another workspace requires an active membership; a posted workspace identifier does not grant access.

Verified accounts and hosted payments

Account verification and recovery use expiring, single-use links. Password changes and membership revocation invalidate older browser access. Team invitations have a finite seat allowance and require the current inviter to retain the necessary permissions.

Stripe hosts checkout and card handling. Subscription allowances require verified payment evidence; returning from checkout does not grant credits. A credit is reserved before a generation task is queued, and uncertain provider charges remain on hold for review.

Approval before public sharing

Public audit access is tied to the current approved script and video. Changing the underlying approval state can invalidate access. The page serves the approved media through the platform and does not expose internal storage locations, provider payloads, or the recipient’s email address.

Expiring invitations, with explicit limits

Private audit URLs act as invitations: anyone with a valid link can view the page. An operator can choose an expiry, rotate the invitation, or revoke it. The server checks access again when the page, video, tracking endpoints, or associated booking flow are requested.

These pages are excluded from public indexing, social metadata containing prospect details, and public sitemaps. Keep invitations with their intended audience; a search directive is not a substitute for protecting the link.

Optional first-party playback insights

Video playback does not require analytics consent. Playback events are collected only after the recipient enables them, and browser Do Not Track and Global Privacy Control preferences disable collection. Playback session credentials are short-lived and are not exposed in browser-visible API responses.

A play and timed progress reaching 75% can inform follow-up. They are client-reported signals and are not a guarantee of human attention. Read the playback and booking data explanation.

Appointment and contact data

Public booking availability shows available times. A reservation’s name and email address are available to authorised operators, while public confirmation responses contain appointment metadata. Cancellation uses a separate browser-held credential.

The system confirms reservations on screen and checks for overlapping appointments on the server. Meeting arrangements are handled by the operator.

Deployment and ongoing care

The application separates browser capture, generation providers, storage, and operator access. A live installation still needs an appropriately secured host, HTTPS, backups, current dependencies, configured providers, and a responsible operator. These controls do not establish a security certification or eliminate all risk.

If you need to discuss a private audit or reservation, contact the operator who sent the invitation or manages the appointment. Avoid forwarding a private link more widely while reporting a concern.