WhatsApp Business Integration & Platform Data Use

Edugopolis provides a multi-tenant WhatsApp Business API integration service for our clients. We access WhatsApp Platform Data only to deliver and track messages on behalf of those clients.

0  Configuration details we ask the client to provide

  • WhatsApp Business Account ID (WABA ID) – used to list the business’s phone numbers and manage the webhook subscription.
  • Business Phone Number ID – the identifier used by the Cloud API to send replies and to map incoming webhook events to the correct tenant.
  • App ID & App Secret / System-User Access Token – credentials authorized by the client to manage the webhook and send replies. We store them encrypted and never log secrets in plaintext. Clients can rotate or revoke them at any time from the settings panel.
  • Webhook Verify Token – a client-chosen string used only to complete the webhook verification handshake (echoing hub.challenge).

These credentials are used solely to authenticate Graph API calls and verify webhooks for the client’s own WhatsApp assets.

1  Data we access

  • waba_id and phone_number_id for the client’s WhatsApp Business Account and selected business number.
  • Inbound message content and metadata delivered by the Cloud API (e.g., sender, timestamps), strictly for receiving and replying to client-initiated conversations.
  • Delivery/read status events from webhooks (e.g., sent, delivered, read) to display conversation state in the client dashboard.

We do not use Platform Data for advertising. Access within our system follows least-privilege and all stored data are encrypted in transit (TLS) and at rest.

2  How we use it

  • Receive customer-initiated messages via the WhatsApp Cloud API webhook and route them to the correct client account.
  • Allow authorized agents (or optional AI assistants) to reply within the 24-hour customer-service window; we do not initiate conversations or use message templates.
  • Store only the minimum necessary message data — IDs, timestamps, sender, and body — in an encrypted database; all data are also protected in transit (TLS).
  • Show conversation history and delivery/read status in the client’s private dashboard to support customer service operations.
  • Provide self-service tools to export or permanently delete conversation data on request.
  • Compute aggregated, de-identified analytics (e.g., volume, response time, resolution rates) for the client’s own reporting — never for advertising.

3  Retention & deletion

Deletion on active systems. When a customer deletes messages from the dashboard or closes the account, we promptly remove the corresponding data from our production systems.

Backups. We do not edit backups retroactively. Instead, deleted data are put beyond use: they are not accessed or processed for any purpose and may only re-appear in a disaster-recovery restore. Backups expire automatically under our defined retention schedule; if we must restore from a backup, we re-apply prior deletions as part of the recovery process.

Cryptographic erasure (where feasible). Where technically possible, we use per-tenant encryption keys to enable cryptographic erase (key destruction), so encrypted data remain inaccessible even if present in backups.

Encryption and access control. Data are encrypted in transit (TLS) and at rest, and internal access follows least-privilege roles.

Customer rights. Customers can export or request deletion of their data at any time; we delete on active systems immediately and handle backups as described above.

4  Security & Access Controls

  • Least-privilege, tenant-isolated access. Internal access is granted strictly on a need-to-know basis and is auditable.
  • Secure transport: all traffic to Meta APIs uses HTTPS/TLS 1.2+ with certificate validation.
  • Encryption at rest: Platform Data are stored encrypted (e.g., AES-256) in line with Meta’s data-security guidance.
  • Protected credentials: Graph API calls are authenticated with access tokens; we enforce periodic key/secret rotation and staff Multi-Factor Authentication.
  • Operational integrity: audit logging, monitoring, and alerting to detect anomalous access or misuse.

5  Analytics

We compute aggregated, de-identified analytics (e.g., conversation volumes, response times, delivery/read rates) so each client can measure support performance. We do not use Platform Data for advertising or cross-client profiling.

6  Compliance

Our practices comply with the Meta Platform Terms, the WhatsApp Business Messaging Policy, the Meta Developer Policies, and Meta’s Data Security Requirements (including encryption in transit and at rest), as well as applicable data-protection laws.

Company details

Edugopolis (commercial brand of Bisnistec E.I.R.L.)
RUC 20601344310
German Schreiber 276, San Isidro, Lima, Peru
atencionalcliente@edugopolis.com