Trust

Every business's data stays its own.

This page describes SET's actual architecture, not aspirational claims. Where something isn't built yet, we say so.

Tenant isolation

Every table that holds business data has row-level security enabled and enforced by Postgres itself — not just application logic. A business's data is scoped to that business at the database layer, the same layer that would have to be compromised to bypass it.

Location-scoped permissions

A multi-location business can scope a staff member to specific locations. That scope is enforced server-side against the authenticated session — never trusted from a URL parameter or client-supplied value.

Private file storage

Photos and documents attached to work live in a private storage bucket. There is no public bucket and no raw path exposure — every file is reached through a short-lived signed URL, generated only after a server-side authorization check.

Hashed, capability-scoped links

Booking, tracking, and appointment-management links use randomly generated tokens. Only a hash of the token is ever stored — the raw token exists for a moment at issue time and is never recoverable from the database afterward. Each link is scoped to specific capabilities (view, approve, reschedule) rather than granting blanket access.

Rate-limited public surfaces

Public booking and availability lookups are rate-limited server-side, independent of any browser-side control an attacker could bypass.

No guesswork identity matching

A customer is never silently matched to an existing record by guessing from a phone number or email. Identity resolution happens through explicit, authenticated staff action or a token the business itself issued.

What we don't claim

SET is not currently SOC 2 certified, HIPAA compliant, or ISO certified. If a formal certification matters for your business, talk to us directly before relying on this page as a substitute.

Questions about security or a specific requirement? Reach us at security@teset.app.