Security

Infrastructure and Hosting

Encryption

Authentication and Access Control

• Role-based access control: PLATFORM_ADMIN, ADMIN, STAFF roles with method-level enforcement
• JWT Bearer token authentication for all API calls
• API Key authentication for programmatic integrations (keys hashed at rest)
• Workspace isolation - all data scoped to workspace; cross-workspace access requires explicit PLATFORM_ADMIN role
• Staff invitation flow - invited users must verify email before accessing a workspace
• Password reset via time-limited, single-use email tokens

WhatsApp Webhook Security

• All incoming Meta webhooks are verified using HMAC-SHA256 signature (X-Hub-Signature-256 header)
• Webhooks without a valid signature are rejected with HTTP 403
• Webhook GET verification uses per-workspace SHA-256 hashed verify tokens
• Inbound messages are deduplicated by WhatsApp message ID (wamid) to prevent replay processing
• Rate limiting applied on all public endpoints (webhook endpoints: 600 requests/min)

Application Security

• All schema changes are managed through versioned Flyway migrations. No ad-hoc DDL is used in production.
• Hibernate DDL mode: validate - Flyway is the sole schema authority
• Input validation on all API endpoints via Spring Validation
• Template variable validation - numeric variables rejected, named variables validated on create/update
• Opt-in/opt-out compliance enforced at application layer before message delivery
• 24-hour WhatsApp customer service window enforced in CommunicationModule (single enforcement point)

Operational Security

• Scheduled jobs use distributed locking to prevent duplicate execution in multi-instance deployments
• Failed webhook deliveries retried with exponential backoff (3 attempts: 1s, 2s, 4s)
• Dead letter logging for failed webhook deliveries after max retries
• All security-relevant events (opt-outs, token lookups, failed auth) are logged
• Quality rating degradation monitoring every 6 hours with circuit breaker

Vulnerability Management

We conduct regular dependency audits and aim to apply critical security patches within 7 days of public disclosure. OptimReach shall undergo a comprehensive penetration test at least once every 12 months and additionally following significant changes to the application's architecture, authentication/authorization mechanisms, APIs, integrations, payment functionality, or other security-sensitive components. Major releases shall undergo targeted security testing covering the functionality and attack surface affected by the release. Critical and high-risk findings shall be remediated and independently retested before production release where practicable.

To report a security vulnerability: security@optimreach.in

Breach Notification

In the event of a confirmed Personal Data Breach, we will notify affected Customers within 72 hours of becoming aware, as required by GDPR Article 33 and the DPDP Act 2023. Notifications are sent to the email address registered on the Customer account.

To report a suspected security incident: security@optimreach.in

Sub-processors

A full list of sub-processors is available at optimreach.in/sub-processors. Changes are notified at least 14 days in advance.

Compliance Summary