A practical overview of how RelayBoard protects workspace access, credentials, browser requests, billing boundaries, exports, and deletion workflows.
Reading key
01—10
Current controls
Each row separates controls handled directly by RelayBoard from responsibilities handled with a named service provider.
01
WorkOS AuthKit provides the primary sign-in and identity session flow.
RelayBoard saves session values in HttpOnly, SameSite=Lax cookies and marks them Secure in production or when the configured app URL uses HTTPS. Workspace access also requires an active, verified local profile linked to the session.
02
Authenticated requests resolve a workspace profile before protected data is loaded.
Workspace services use company-scoped queries and server-side permission checks. Administrator permissions are fixed; manager and employee permissions can use company-specific overrides when the plan enables that capability.
03
The application adds response security headers and validates the origin of browser API mutations.
Current headers include a nonce-based Content Security Policy for pages, frame restrictions, HSTS, MIME sniffing protection, a referrer policy, and disabled camera, microphone, and geolocation permissions.
04
Stored Apple, Google, and Microsoft calendar credentials are encrypted before database storage.
RelayBoard uses authenticated AES-256-GCM encryption for calendar connector credential fields. This control is limited to the stored credentials and tokens used by Apple, Google, and Microsoft connections.
05
Pro API keys are hashed and webhook signing secrets are encrypted before database storage.
API key plaintext and webhook signing plaintext are each displayed once. Keys have explicit scopes, optional expiry, rotation, revocation, creator attribution, and current server-side permission checks. Outbound webhook delivery revalidates public HTTPS DNS answers per attempt, rejects redirects, signs the exact body, retries with a bound, and stores redacted outcomes.
06
Paddle renders checkout and processes payment details.
RelayBoard stores the provider identifiers, plan, and subscription state needed to manage access. Card numbers are handled by Paddle and are not stored by RelayBoard.
07
Sensitive and resource-intensive routes use fixed-window request limits.
Limits are applied to account access, error reporting, and other sensitive or resource-intensive routes. Production readiness checks verify that the selected rate-limiting mode is available.
08
RelayBoard uses Sentry for errors, sampled performance traces, and operational logs.
Default PII sending is disabled, application context is sanitized, and user context is limited to pseudonymous profile and workspace identifiers plus role. Session replay is currently off; if enabled later, text, inputs, and media are configured to be masked or blocked.
09
Workspace administrators can download a versioned JSON snapshot of workspace business data.
Every exported collection is scoped to the authenticated administrator's company. Credentials, session material, access codes, calendar tokens, and billing provider identifiers are excluded. Successful exports create a metadata-only audit event and responses are marked private and no-store.
10
Administrator-requested workspace deletion runs as a retryable cleanup job rather than an immediate browser action.
The job cancels non-terminal Paddle subscriptions and removes linked WorkOS identities that are not used by another workspace before deleting the local company record. If cleanup fails, the workspace remains available for a retry. Provider-managed records may follow separate retention obligations.
Scope note
This page describes current product controls and the boundary of each named service. It is not a security certification or an independent audit report.
Privacy requests and policy questions can be sent to supportrelayboard.app. For how RelayBoard handles information, read the Privacy Policy.