How Wappline protects your data

Overview

Wappline connects your business accounts on WhatsApp, Instagram and Telegram, routes conversations to your team and runs automations and campaigns on top of them. To do that it stores five kinds of data.

Account data

Team members with their role and permissions, sign-in records and the details used to invoice you.

Channel connections

The access tokens and identifiers that let Wappline send and receive messages on your behalf.

Conversations

Contacts, conversation status, notes and tags, and the content of every message.

Media

Images, audio, video and documents sent or received in conversations.

Configuration

Automations, campaigns, templates, forms and webhook endpoints.

Every company account is a separate tenant. Channels, conversations, messages and other records carry the company they belong to, and queries made for a signed-in company user are restricted to that company by model-level scopes.

Wappline stores what it needs to deliver and display your conversations and to run the features you switch on.

Encryption

At rest

These values are encrypted with AES-256-CBC before they are written to the database. The key is held in the server environment, not in the database.

• Channel access tokens, including Telegram bot tokens, and the Meta tokens of your company account.
• Bitrix24 access, refresh and application tokens.
• The secrets of automation webhook triggers.
• API keys you connect for automation steps, kept in a company credential store instead of inside the automation.
• Message content: every inbound and outbound message is encrypted before it is stored, and a message that cannot be encrypted is not stored.
• Two-factor authentication secrets and recovery codes.

Some values are stored as one-way SHA-256 digests instead, so the original cannot be read back: the secret that authenticates Telegram updates for a channel and the two-factor recovery codes.

Contact names and identifiers, conversation details such as the preview of the latest message (limited to 100 characters), media files and configuration are protected by access control rather than by field-level encryption.

In transit

The Wappline web server accepts only TLS 1.2 and 1.3, redirects requests over plain HTTP to HTTPS and sends an HTTP Strict Transport Security header with a lifetime of one year. Pages also send X-Content-Type-Options, Referrer-Policy and X-Frame-Options headers.

Media access

Media files are never served from a public address. Each file is delivered through a signed link that expires and is bound to one company. Links shown in the inbox and returned by the API are valid for 1 hour. Links handed to systems that cannot ask for a new one, such as Bitrix24 Open Lines and webhook payloads, are valid for 7 days. A signed-in user of a different company cannot use the link.

Webhooks

Webhooks sent to Wappline

Wappline accepts events from channels only when they prove where they come from.

Meta

Events for WhatsApp and Instagram must carry an X-Hub-Signature-256 header: an HMAC-SHA256 of the raw request body made with the Meta app secret. A missing header, a missing app secret or a mismatch is rejected with status 403. The check fails closed.

Replay protection

A Meta message whose own timestamp is older than 5 minutes is dropped. Repeated deliveries are recognised and processed once: message and status identifiers are remembered for 5 minutes, Telegram update identifiers for 10 minutes.

Telegram

Every Telegram channel has its own webhook address and its own secret. Telegram sends the secret in the X-Telegram-Bot-Api-Secret-Token header. Wappline stores only a SHA-256 hash of it and compares in constant time. A wrong or missing secret is rejected with status 403.

Bitrix24

Requests are accepted only with the application token stored for your portal, or with an access token that Bitrix24 itself confirms for that portal. A wrong token is rejected.

Webhooks Wappline sends to you

Events from a channel can be delivered to endpoints you configure on that channel. Every delivery is signed, so your endpoint can check that it came from Wappline.

Signature

X-Webhook-Signature carries sha256= followed by the HMAC-SHA256 of the timestamp, a dot and the raw body, made with the secret of the endpoint. X-Webhook-Timestamp is the Unix time of the attempt.

Context headers

X-Webhook-Event, X-Instance-Id and X-Channel identify the event, the channel in Wappline and the channel type.

Retries

A delivery is attempted up to 5 times, waiting 10 seconds, 30 seconds, 2 minutes and 10 minutes between attempts. Each attempt times out after 10 seconds and is recorded in the delivery history of the endpoint. You can also send a test event from the endpoint settings.

Automatic pause

After 10 consecutive failed attempts an endpoint is paused and stops receiving events until you resume it. A successful delivery resets the count.

Secret rotation

You can rotate the secret of an endpoint at any time, after a password confirmation. For 24 hours after a rotation, deliveries also carry X-Webhook-Signature-Previous, signed with the previous secret, so you can switch without downtime.

Verifying a delivery in PHP

Compare signatures with hash_equals and reject deliveries whose timestamp is far from the current time. The five-minute tolerance in the example is a recommendation for your endpoint, not a limit Wappline enforces.

$secret    = getenv('WEBHOOK_SECRET');
$timestamp = $_SERVER['HTTP_X_WEBHOOK_TIMESTAMP'] ?? '';
$signature = $_SERVER['HTTP_X_WEBHOOK_SIGNATURE'] ?? '';
$body      = file_get_contents('php://input');

// Signature over "timestamp.body", as Wappline signs it
$expected = 'sha256=' . hash_hmac('sha256', $timestamp . '.' . $body, $secret);

if (! hash_equals($expected, $signature)) {
    http_response_code(401);
    exit;
}

// Reject old deliveries
if (abs(time() - (int) $timestamp) > 300) {
    http_response_code(401);
    exit;
}

Network protection

Wappline makes requests to addresses you provide: webhook endpoints, HTTP request and webhook steps in automations, and the endpoint of a custom provider in an automation step. All of them go through one guard that applies these rules.

• Only http and https addresses are allowed.
• Addresses written as decimal, octal or hexadecimal numbers are rejected, and so are IPv6 literals and well-known internal host names such as localhost and cloud metadata hosts.
• The host name is resolved and every address it returns is checked. Private, loopback, link-local, shared (carrier-grade NAT) and other reserved ranges are refused.
• The connection is pinned to the address that was checked, so a second DNS answer cannot redirect the request.
• Redirects are followed one hop at a time, at most 3 redirects, and each hop is checked again. Credential headers are dropped when a redirect leaves the original host.
• Connections time out after 5 seconds, a request may take 1 minute at most, and responses are capped at 1 MiB.

Access control

Roles

Company administrator

Full access to the company account, including team, plan and billing details, API tokens, data export and deletion, campaigns and forms. Every permission is implied.

Team member

A company administrator grants access one permission at a time, and a member sees only the channels assigned to them.

Wappline personnel

Platform administrators and support operators work in separate areas. Customer accounts cannot open them, and personnel accounts cannot open the customer area.

Permissions an administrator can grant

• Use the shared inbox and open conversation transcripts.
• Open the dashboard reports.
• Connect and manage channels.
• Create and edit automations.
• Open the API documentation.
• Show the data export entries in the menu. Exporting and deleting company data stays with company administrators.
• Open content management and its analytics.
• Publish, schedule and reply to comments in content management.

On the Enterprise plan, customer isolation can be switched on for a company account so that each of your own customers is given only the channels and conversations assigned to them.

Sign-in and account controls

Password policy

At least 10 characters with upper and lower case letters and a number. In production, passwords known from public data breaches are rejected.

Sign-in attempts

After 5 failed attempts for the same email address and network address, further attempts are blocked for a short time. Registration and password reset requests are rate limited as well.

Sessions

Changing a password signs out every other session and invalidates remember-me cookies. Session cookies are HttpOnly, SameSite=Lax and marked Secure on HTTPS.

Role changes

Changing the role or permissions of a team member asks for a fresh password confirmation and is written to the audit log.

Invitations

Invitations to join a team are signed links that expire after 72 hours.

Two-factor authentication

Two-factor authentication is optional and set per user. It uses time-based one-time passwords (RFC 6238) from an authenticator app. When it is on, a correct password is followed by a code challenge. A code can be used once, and after 5 wrong codes within a minute further attempts are blocked. 8 single-use recovery codes are issued, and only their SHA-256 digests are stored. Turning it on or off sends an email and is written to the audit log.

Session overview

The account security page lists active sessions with device and network, and lets a user sign out one other session or all of them. A sign-in from a device not seen in the last 90 days sends an email alert.

API security

Authentication

The REST API uses two tokens: a company token (X-Company-Token) and a channel token (X-Instance-Token). A channel token is accepted only together with the token of the company that owns the channel. Inactive companies and frozen channels are refused.

Rate limits

Each token pair is limited to 300 requests per minute. Requests without both tokens are limited to 60 requests per minute per IP address, and a token pair that has not been validated yet counts against that address limit as well, so guessing tokens does not get around it.

Idempotency

Send requests accept an Idempotency-Key header. A repeated key within 24 hours returns the first result with Idempotent-Replayed: true instead of sending the message again, and a duplicate that arrives while the first request is running is answered with status 409.

Token rotation

A company administrator can rotate the company token and any channel token, after a password confirmation and at most 5 times per minute. The previous token stops working as soon as the new one is issued. Revealing tokens in the interface is recorded in the audit log.

Audit log

Wappline keeps an append-only audit log of security-relevant and privileged actions. Each entry records who acted, when, from which IP address and which record was affected. Entries describe what happened without storing token or secret values, and a failed sign-in never stores what was typed.

What is recorded

Sign-in and account security

Sign-ins, failed sign-ins and sign-outs, password changes and resets, two-factor changes, session revocations and account deletion requests.

Users and team

Team invitations and removals, role and permission changes, deactivation and reactivation.

Company accounts

Company creation and changes, suspension, deletion, enterprise isolation and internal notes.

Plan and billing

Plan changes and purchases of extra channels, billing status and billing details.

Tokens and secrets

Company and channel token rotations, webhook secret rotations and token reveals.

Platform administration

Integrations, channel and automation deletion, log maintenance and announcements.

Support

Support operator actions on customer channels and canned replies.

Data and conversations

Data export downloads, conversation transcript exports, bulk conversation updates and data deletion requests.

Wappline platform administrators can review the full log. Company administrators see the entries about their team members, such as invitations, role and permission changes, plan changes and token events, in the activity panel on the team page. Entries are kept for 365 days, see the retention table.

Data retention

Operational records are removed automatically after fixed periods. The periods below are read from the platform's own configuration, so this table changes when the platform does.

Export and deletion

Export

Company administrators can export company data from the account: choose the categories (company details, team members, channels, messages, conversations, workflows, campaigns, forms, content and more), pick a ZIP archive of CSV files or a single JSON file, and download it when it is ready. Tokens, secrets and passwords are redacted from exports. Export files are deleted after 30 days, and every download is written to the audit log.

Account and company deletion

A company administrator can request deletion of the whole company account, and any team member can request deletion of their own account. A request is not carried out at once: there is a cooling-off period of 3 days, a reminder email 24 hours before the deadline, and the request can be cancelled until then. If the last company administrator deletes their account, the whole company account is deleted with it.

When the deletion runs it removes the company's records, users, stored media files, export files and content files from the platform.

Meta data-deletion callback

When someone removes the Wappline app from their Facebook account, Meta calls the data-deletion callback. Wappline verifies Meta's signature, creates a request with a confirmation code and removes the Meta tokens and the Meta channels (WhatsApp and Instagram), with their data, of the company accounts linked to that Meta user. Users, the company account, Telegram and Bitrix24 data are left in place. The status page is at /data-deletion/status?code= followed by the confirmation code.

Roles under KVKK and GDPR

For conversation data you are the data controller (veri sorumlusu) and Wappline is your data processor (veri işleyen). The messages, contacts and media that pass through your channels are processed to deliver, display and automate your conversations.

For account and billing data, Wappline is the data controller: the names and email addresses of users, sign-in records and the details used to invoice you.

Requests about your own data, including requests under article 11 of the KVKK and the data subject rights of the GDPR, go to [email protected]. The privacy policy describes purposes, legal bases and your rights.

• Privacy policy
• KVKK notice

Sub-processors

These providers process data on Wappline's behalf to run the platform. AI providers you connect with your own API key and your own webhook endpoints are services you connect, not Wappline sub-processors.

Responsible disclosure

If you believe you have found a vulnerability in Wappline, email [email protected].

Machine-readable contact: /.well-known/security.txt

What to include

• The affected page, endpoint or feature.
• Steps to reproduce the issue.
• What an attacker could do, and which data is affected.
• How to reach you, and whether you want to be credited.

Guidelines for good-faith research

• Test only with accounts you own or have permission to use.
• Do not access, change or keep other people's data beyond what is needed to show the issue.
• Do not run denial-of-service or spam tests, and do not use social engineering against staff or customers.
• Give us reasonable time to fix the issue before you publish details.

We review every report and keep you informed about the outcome. We welcome good-faith research that follows these guidelines and will work with you to understand and fix what you find. This page describes how we handle reports and is not a legal agreement.