Security
How LinkTime protects your data, credentials, and integrations.
Overview
LinkTime is built with security as a foundational principle. Your scheduling data, OAuth tokens, and integration credentials are protected by multiple layers of encryption, authentication, and verification. This page describes the security measures in place across the platform.
The codebase is fundamentally solid — AES-256-GCM encryption, Clerk middleware, Zod validation, CSRF protection, rate limiting, webhook signatures (Stripe, Twilio), and timing-safe comparisons are all in place. We conduct regular security audits and address findings promptly.
Encryption at Rest
All sensitive credentials — OAuth access tokens, refresh tokens, and API keys for your connected integrations — are encrypted at rest using AES-256-GCM (authenticated encryption). This means even if the database were compromised, tokens would be unreadable without the encryption key.
- ✓Google, Outlook, Zoom, HubSpot, Attio, Salesforce, CalDAV, and Twilio tokens are all encrypted
- ✓Encryption key is a required environment variable — the app will not start without it in production
- ✓GCM mode provides both confidentiality and integrity (tampered ciphertext is rejected)
Authentication
LinkTime uses Clerk for authentication, providing secure sign-in with Google and Microsoft OAuth. Authentication is enforced at the edge (middleware) before any route handler executes.
- ✓Edge middleware validates session tokens on every request to protected routes
- ✓API routes verify authentication before processing — no unauthenticated data access
- ✓API keys for external access use SHA-256 hashing — only the hash is stored, never the raw key
Input Validation & CSRF Protection
All user input is validated using Zod schemas before processing. This prevents injection attacks, malformed data, and unexpected behavior.
- ✓Booking forms, API endpoints, and webhook payloads all use strict Zod validation
- ✓CSRF token protection on booking form submissions prevents cross-site request forgery
- ✓SOQL injection prevention in Salesforce queries (single quotes escaped)
Webhook Signature Verification
All inbound webhooks are verified using cryptographic signatures to ensure they come from legitimate sources.
| Provider | Method | Header |
|---|---|---|
| Stripe | HMAC-SHA256 (timing-safe) | stripe-signature |
| Twilio | HMAC-SHA1 (URL + params) | x-twilio-signature |
| PayPal | Webhook ID verification | PayPal IPN verification |
Rate Limiting
Public-facing endpoints are protected by Upstash Redis-based rate limitingto prevent abuse and denial-of-service attacks. Rate limits are applied per-IP on booking creation and other high-value endpoints.
Internal Endpoint Protection
Cron jobs and internal endpoints are protected by a shared secret (Bearer token). The app requires this secret to be set in production — it will not start without it. The secret is validated centrally with minimum length requirements.
Integration Token Lifecycle
OAuth tokens for connected integrations (Google, Outlook, HubSpot, Attio, Salesforce) are managed with proactive refresh and automatic disconnection:
- ✓Proactive refresh: Tokens are refreshed 5 minutes before expiry — no failed requests from stale tokens
- ✓Auto-disconnect: If a token refresh fails (revoked or expired), all integration fields are cleared automatically
- ✓Fire-and-forget: CRM and calendar sync errors never block booking creation — your core scheduling always works
Infrastructure
- ✓Hosting: Railway (SOC 2 compliant infrastructure)
- ✓Database: PostgreSQL with encrypted connections (SSL)
- ✓HTTPS: All traffic encrypted in transit with TLS
- ✓Environment variables: Validated at startup — missing required variables crash immediately (fail-fast)
Reporting Vulnerabilities
If you discover a security vulnerability, please email [email protected]. We take all reports seriously and will respond promptly.