Security and control

Evidence-based security notes for Vasiva Relay: data flows, extension permissions, JWT access, email notifications, session interruptions, sign-out limits, and what we do not claim.

How does Vasiva Relay handle security?

Vasiva Relay is a WhatsApp enquiry workflow product that acknowledges incoming enquiries, applies configured contact tags, notifies internal teams and records activity.

Also known as

Vasiva Relay is the same product referred to on the Vasiva parent brand site as Vasiva First Reply / First Reply.

Parent brand page: https://vasiva.co/products/first-reply

Workflow

  1. Acknowledge
  2. Tag
  3. Notify
  4. Track

Available today

What Relay is not

Who it is for

Businesses that receive customer enquiries through WhatsApp and need the repetitive first operational steps handled consistently.

Requires

Browser session

Relay uses your existing WhatsApp Web browser session. If Chrome closes, the extension is disabled, WhatsApp Web logs out, or the network drops, automatic acknowledgements pause until the session and extension are available again.

Direct answer

Vasiva Relay uses JWT-authenticated workspace access with audience checks, multi-tenant scoping, rate limits, request sanitisation, local encryption helpers for sensitive browser storage, Fernet helpers for selected backend secrets when configured, and operator controls such as automation ON/OFF. Enquiry data needed for matching and acknowledgements is processed by the extension and the authenticated backend. We do not claim SOC 2, ISO, Meta partnership, zero-risk automation, or automatic deletion of all data when the browser closes.

Security summary

Data Relay accesses

Through the Chrome extension on WhatsApp Web, Relay can observe inbound chat signals needed for automation: sender identity fields available in the page, message text used for keyword matching, chat identifiers (1:1 only — groups are skipped), and connection/status signals. Relay does not require Meta Cloud API credentials for the default browser-session workflow.

Data stored locally in the browser

The extension stores workspace configuration and operational state in chrome.storage.local (for example backend URL, automation ON/OFF, bound phone identity flags, message activity cache, contacts cache, and scheduled job metadata). Sensitive values written through the product’s local encryption helpers use AES-GCM via the Web Crypto API with a per-device derived key. Browser storage is not a substitute for server access control, and encryption falls back to plaintext if Web Crypto is unavailable.

Data sent to Vasiva-controlled systems

When connected, the extension forwards inbound enquiry events to the Relay backend over HTTPS/WSS (including sender fields, message text used for matching, client/workspace identifiers, and automation flags). The backend persists operational records such as contacts/tags, workflow runs, activity, and email dispatch logs for the authenticated workspace.

Data handled by WhatsApp / Meta

Message transport and the WhatsApp Web session remain under Meta’s WhatsApp products and terms. Vasiva Relay is independent software and is not a Meta Business partner product by default. Closing or logging out of WhatsApp Web stops Relay’s browser-based acknowledgements for that session.

Email notifications

Configured internal notifications are sent through the platform SMTP path (PLATFORM_SMTP_*). Recipients come from the workflow configuration or a verified notification email on the workspace profile. Failed sends are recorded in email logs; Relay does not claim end-to-end encryption of notification email content.

Extension permissions

The Manifest V3 extension requests storage, tabs, activeTab, scripting, alarms, sidePanel, and notifications, plus host access to WhatsApp Web, wa.me, and the Vasiva Relay API/WebSocket hosts (with optional broader *.vasiva.co hosts). These permissions support DOM automation, local state, keep-alive, and backend connectivity — not unrestricted browsing of unrelated sites.

Access controls

API and WebSocket access use JWT authentication with separate audiences for product API, portal, and admin surfaces. Workspace data queries and workflow evaluation are filtered by client/workspace identifiers derived from the authenticated identity. Login endpoints use rate limiting; request sanitisation middleware reduces NoSQL operator injection in request bodies.

Sensitive configuration at rest

Where the backend stores sensitive integration secrets (for example Cloud API tokens when that feature is configured), Fernet encryption helpers are used when ENCRYPTION_KEY is provisioned. Production startup validation requires a valid encryption key. Development misconfiguration can store values unencrypted — production must not use development defaults.

Logging and error reporting

Operators can review Activity for matched enquiry runs. The backend writes operational and audit records for authentication and workflow events. Some PII patterns (for example OTP-like codes) are masked before local message-log persistence in the extension. Audit log documents in MongoDB are configured with a time-to-live index (90 days) on timestamp — other collections do not automatically inherit that retention unless separately configured.

Session handling

Relay depends on an authenticated workspace session (JWT) and a live WhatsApp Web browser session bound to the expected business number. Phone mismatch locks automation. WebSocket disconnect queues events when offline. JWT logout revokes the refresh path when the logout API succeeds.

Sign-out, local clear, and deletion limits

Sign out clears the local auth token and selected identity flags and calls the logout API when possible; it does not by itself delete server-side contacts, workflows, or activity history. Settings can clear local event logs (wa_event_log, wa_msg_count, wa_alerts). Full workspace data deletion or export is an account/support process — do not assume automatic erasure of all Relay data when you close the browser.

Known limitations

Browser automation is not ban-proof and is not equivalent to the official WhatsApp Business Platform. Vasiva does not claim Meta approval for the WhatsApp Web path. Automation pauses when Chrome, the extension, WhatsApp Web, or the network is unavailable. Local encryption is best-effort. Notification email depends on SMTP configuration. Optional advanced tools (outbound quotas, contact export) are not the core first-response product and increase operational risk if used. See the dated policy review in docs/whatsapp_policy_review.md (not legal advice).

Session interruptions

Chrome closes

WhatsApp Web is no longer available in a tab. Browser-based acknowledgements stop until Chrome is open again with WhatsApp Web and the extension loaded.

Extension disabled or removed

Content scripts and the service worker stop. No new inbound detection or DOM replies run from Relay until the extension is enabled again and connected.

WhatsApp Web logs out

The WhatsApp session ends. Relay cannot send acknowledgements through that browser session until you log in again and identity checks pass.

Network disconnect

Backend WebSocket/API calls may fail. Events can queue locally while offline; workflows that need the backend or an active WhatsApp tab may not complete until connectivity returns.

Auth session expires or sign-out

API calls that require a JWT fail until you sign in again. Sign-out clears the local token; server workspace data remains until separately deleted through an account process.

Automation exception or phone mismatch

Failed steps can appear in Activity. A WhatsApp number mismatch blocks automation until the bound identity matches again.

Security contact

[email protected]