Security is part of the booking flow.

Our security approach combines identity controls, workspace isolation, conservative payment handling, abuse prevention, auditability, and operational checks. Controls are designed around the actual risks of a multi-workspace scheduling platform: unauthorized account access, cross-workspace data exposure, fraudulent booking traffic, forged payment events, leaked credentials, and missed background work.

• Passwords are stored using an adaptive salted password hash, never as readable passwords.
• Workspace sessions are signed, HTTP-only, SameSite cookies; production cookies are restricted to secure HTTPS transport.
• Session and staff security epochs allow account, password, pause, suspension, and email-verification events to invalidate existing sessions.
• Sign-in, password reset, activation, registration, support, demo, and administrator verification endpoints are rate limited.
• New workspace owners must verify their email before the workspace becomes active, and requested sign-in email changes remain pending until the new address is confirmed.
• Workspace staff can enable two-factor authentication for their own account, and workspace owners can require a second sign-in step for every staff member.
• Workspace two-factor authentication supports emailed verification codes and authenticator-app codes. An authenticator app can be preferred, while email remains available as a recovery method.
• Platform-administrator access always requires a second factor, with short-lived pending authentication and support for authenticator-app verification.
• One-time activation and reset tokens are random, time-limited, single use, and stored only as cryptographic hashes.

• Every administrative request is authorized against a specific workspace identifier and active workspace status.
• Signed session claims are checked against the current tenant, staff member, role, active state, and revocation counters.
• Owners and staff have distinct permissions; staff booking visibility is restricted to assigned records where applicable.
• Integration access uses workspace-specific bearer tokens stored as hashes and compared using timing-safe checks.
• The public demo carries a signed demo claim whose writes are confined to an allow-list of booking, contact, resource and template routes, enforced both at the request boundary and inside authorization; staff accounts, billing, payments and outgoing email are always refused, and the workspace is rebuilt nightly.
• Database relationships and tenant filters provide additional ownership boundaries for resources, contacts, staff, invoices, and related records.

• Authenticated unsafe requests are checked against trusted origins to reduce cross-site request-forgery risk.
• Security headers restrict framing, content types, referrer leakage, browser permissions, script and connection sources, and embedded payment origins.
• Public and authentication routes use Redis-backed rate limiting when configured, with a local fallback if Redis is temporarily unavailable.
• Inputs are validated at API boundaries, and database constraints protect critical uniqueness, status, payment, capacity, and ownership invariants.
• Sensitive actions require current-password confirmation, owner authorization, platform-administrator authorization, or signed provider events as appropriate.
• The production service requires configured secrets rather than falling back to development credentials.

• Card entry and payment collection use Stripe-hosted Checkout; Bookhurst does not store full payment-card numbers.
• Stripe webhook signatures are verified against the configured signing secret before an event is accepted.
• Payment fulfillment and refunds are tenant-scoped and reconciled against Stripe identifiers and connected-account context.
• Checkout capacity holds expire and are reconciled so stale or missed events do not indefinitely block availability.
• Transactional and CRM emails are sent through the configured delivery provider; delivery status is recorded without exposing provider credentials to the browser.
• Cron and background-work entry points require deployment secrets or execute inside the trusted worker process.

• Application secrets and provider credentials are supplied through server-side environment configuration and are not intentionally exposed to client bundles.
• Workspace integration tokens and one-time account tokens are stored as cryptographic hashes; newly generated integration credentials are shown only once.
• Workspace-staff and platform-administrator authenticator secrets are encrypted at rest using authenticated encryption.
• Payment records store operational amounts, status, fees, refunds, and provider identifiers—not full card credentials.
• Audit and activity records preserve important administrative, CRM, and workspace state changes for investigation and accountability.
• Transport encryption depends on HTTPS being correctly enforced by the production host or reverse proxy.

Our Privacy Policy describes the information processed, providers involved, retention approach, and available privacy choices.

• A readiness endpoint checks database availability and reports worker state for deployment monitoring.
• Automated CI runs dependency installation, linting, tests, and the production build before changes are accepted into a normal deployment workflow.
• Versioned database migrations make schema changes reviewable and reproducible.
• The reminder and payment-reconciliation worker records failures and can catch up work after interruption.
• The web server continues serving when background-worker startup fails, allowing health and customer-facing recovery paths to remain available.
• Operational documentation identifies production monitoring, migration, backup, and restore responsibilities.

Suspected security events are evaluated for scope, affected systems, containment, credential or session revocation, data integrity, provider coordination, recovery, and required notifications. Platform audit, application, provider, and infrastructure records may be used during an investigation.

If an incident materially affects a workspace or personal information, we will communicate with affected parties as reasonably appropriate and as required by applicable law. Workspace owners must keep their account email current so security notices can reach them.

• Use a unique password and protect the email account used for password resets and verification.
• Grant the least staff access needed, review active staff regularly, and deactivate former team members promptly.
• Rotate an integration token after suspected exposure and never place tokens in browser code, shared documents, chat, or public repositories.
• Protect computers and phones with updates, screen locks, malware defenses, and trusted networks.
• Review Stripe access, payout details, refunds, disputes, and payment reconciliation independently.
• Collect only customer information needed for a lawful business purpose and avoid sensitive data in unrestricted notes.
• Report suspicious access or unexpected messages promptly to support@bookhurst.com.

Security is continuously improved, but no internet service is immune to every vulnerability, provider failure, or human mistake. This page is a current description of implemented safeguards, not a warranty that an incident cannot occur.

Unless separately confirmed in writing, Bookhurst does not claim a particular security certification, independent audit report, penetration test frequency, bug-bounty program, data-residency guarantee, or formal service-level agreement. We will update this page when verifiable assurance material becomes available.

Send suspected vulnerabilities to support@bookhurst.com with “Security report” in the subject. Include the affected page or feature, reproduction steps, expected impact, and a safe way to contact you. Do not include real customer data unless necessary.

• Avoid privacy violations, data destruction, service disruption, spam, social engineering, and access beyond what is needed to demonstrate the issue.
• Do not publicly disclose an unresolved issue before we have had a reasonable opportunity to investigate and address it.
• We will acknowledge a credible report, investigate it in good faith, and communicate material remediation progress when possible.

General account or product questions should use the Support page.