1. Security Architecture Overview
At Slotwise, we treat scheduling security and data autonomy as fundamental platform pillars. Our architecture is built on defense-in-depth principles: zero unnecessary data ingestion, hardened application endpoints, and containerized relational databases with strict access boundaries.
TLS 1.3 Everywhere
Strict HTTPS enforcement with HSTS preloading and modern cipher suites across all endpoints.
AES-256 at Rest
Encrypted OAuth tokens and database volume backups safeguarding sensitive calendar connections.
Zero Telemetry
No invasive advertising scripts, tracking pixels, or cross-site behavioral analytics tags.
2. Encryption & Key Management
We protect data in transit and at rest through proven cryptographic standards:
- Data in Transit: All HTTP connections require TLS 1.3 / 1.2 with perfect forward secrecy (PFS). Unencrypted HTTP requests are automatically redirected with permanent 301 responses.
- OAuth Token Encryption: Google Calendar and Microsoft 365 OAuth refresh tokens are encrypted at rest using AES-256-GCM authenticated cipher with rotating application secrets.
- Bcrypt Password Hashing: Passwords are one-way hashed using bcrypt with adaptive salt cost factors. Plaintext passwords never touch logs or persistent disks.
3. Relational Isolation & Atomic Concurrency
Scheduling collisions and phantom double bookings are severe reliability vulnerabilities. Slotwise eliminates these issues at the database engine level:
• InnoDB Row-Level Locking: Slot reservation queries execute within atomic transactions utilizing SELECT ... FOR UPDATE locks to guarantee single-winner execution even under concurrent millisecond requests.
• Relational Foreign Key Constraints: Multi-tenant isolation is enforced via relational schema design. User accounts, event types, and booking records maintain strict cascade rules.
• Parameterized Queries: 100% of SQL statements utilize prepared statements, completely mitigating SQL injection vulnerabilities.
4. Authentication & Session Hardening
Our authentication architecture is designed to prevent session hijacking and credential stuffing:
HttpOnly SameSite Cookies
Session tokens are isolated from client-side JavaScript execution, providing baseline immunity against XSS token exfiltration.
Adaptive Rate Limiting
Endpoint-specific token buckets protect authentication and booking creation endpoints against brute-force attacks.
5. Attendee Overlay Isolation
Slotwise includes an attendee calendar overlay feature. From a security standpoint, this architecture ensures zero-leakage:
- External calendar data is fetched directly inside the attendee's browser sandbox.
- Attendee appointments are never sent to or cached on Slotwise backend database servers.
- Meeting hosts have zero visibility into attendee external schedules.
6. Backups & Disaster Recovery
We maintain resilient multi-region backup schedules with automated restoration validation:
• Recovery Point Objective (RPO): Under 1 hour for transactional booking databases.
• Recovery Time Objective (RTO): Under 4 hours for full cluster re-provisioning.
• Point-in-Time Recovery: Continuous binary log archiving across geo-redundant storage volumes.
7. Regulatory Alignment & Standards
European General Data Protection Regulation (GDPR)
Full compliance with Articles 25 (Privacy by Design), 28 (Processor terms), and 32 (Security of processing).
India Digital Personal Data Protection (DPDP) Act 2023
Compliant consent mechanisms, designated Grievance Redressal Officer, and straightforward consent withdrawal.
PCI-DSS Payment Compliance
Credit card processing for paid bookings is delegated entirely to Stripe. Slotwise never touches or stores raw card numbers.
8. Coordinated Vulnerability Disclosure
We welcome responsible security research. If you discover a potential vulnerability in our website, API, or booking infrastructure:
Guidelines for Responsible Reporting:
- Email vulnerability details to [email protected] or use the online submission modal.
- Provide sufficient detail and reproducible steps without impacting other users' accounts or modifying production data.
- Allow our engineering team 72 hours to review and triage before public disclosure.
9. Security Inquiries & Contact
For enterprise security audits, vendor assessment questionnaires, or incident reporting: