Skip to main content

Overview

Evolution API is designed from the ground up for multi-tenancy, allowing you to serve multiple customers, departments, or users from a single API installation while maintaining complete data isolation. Key multi-tenant features:
  • Instance-based isolation - Each tenant gets their own WhatsApp instance
  • Database-level separation - All queries are scoped by instance ID
  • Per-tenant authentication - Unique API tokens per instance
  • Client name separation - Logical grouping for multiple API deployments
  • Resource isolation - Memory, connections, and storage per tenant
Think of Evolution API as a “WhatsApp as a Service” platform. Each tenant operates in complete isolation with their own WhatsApp connection, data, and configuration.

Multi-Tenant Architecture

Tenant = Instance

In Evolution API, one tenant = one instance. Each customer, department, or user should have their own instance:
Each instance maintains:
  • Separate WhatsApp connection
  • Isolated message history
  • Independent contacts and chats
  • Custom webhook configurations
  • Unique authentication token

Database Isolation

Evolution API ensures complete data isolation at the database level. Every table includes an instanceId foreign key:
All queries are automatically scoped:
Never query without filtering by instanceId. All Evolution API services enforce this pattern to prevent data leakage between tenants.

Memory Isolation

Each instance runs in its own isolated context:

Building a Multi-Tenant SaaS

Step 1: Design Your Tenant Model

Map your business model to instances:

Step 2: Create Instances Programmatically

When a customer signs up, create their WhatsApp instance:

Step 3: Implement Per-Tenant Operations

All WhatsApp operations use the tenant’s instance token:

Step 4: Handle Webhooks Per Tenant

Route webhooks to the correct tenant:

Client Name Separation

For advanced deployments, use client names to run multiple Evolution API installations against the same database:
From src/api/services/monitor.service.ts:340:
This allows you to:
  • Regional separation - Different API servers per geographic region
  • Environment isolation - Separate dev/staging/production instances
  • Load balancing - Distribute instances across multiple API servers
  • Tenant grouping - Group related customers logically
All API servers share the same database but load only their assigned instances based on clientName.

Instance Naming Strategy

Choose a consistent naming convention for tenant instances:

By Customer ID

By Customer Slug

By Department

By Phone Number

Use lowercase alphanumeric characters and hyphens only. Instance names are permanent and cannot be changed after creation.

Security Best Practices

The global API key grants access to all tenants. Keep it secret:
Each tenant should only access their own instance:
Prevent one tenant from affecting others:
Always verify the tenant owns the resource:
Each tenant should have their own webhook URL:
Enforce limits per tenant to prevent abuse:

Tenant Lifecycle Management

Onboarding Flow

1

Customer Signs Up

Create customer account in your database:
2

Provision WhatsApp Instance

Create Evolution API instance:
3

Display QR Code

Show QR code for customer to scan:
4

Monitor Connection

Listen for connection webhook:
5

Enable Features

Once connected, enable WhatsApp features:

Offboarding Flow

1

Customer Cancels

Mark account for deletion:
2

Export Data

Allow customer to download their data:
3

Logout Instance

Disconnect from WhatsApp:
4

Delete Instance

After retention period, permanently delete:

Monitoring and Observability

Track Instance Health Per Tenant

Usage Tracking

Scaling Considerations

As tenants grow, consider:
  • Indexing: Add indexes on instanceId and remoteJid
  • Partitioning: Partition tables by instanceId or date
  • Read replicas: Use replicas for read-heavy workloads
  • Archiving: Move old messages to cold storage
Scale horizontally with multiple API servers:
Distribute instances across servers using clientName.
Enable Redis for session storage at scale:
This reduces database load for connection state.
Use message queues for high-volume webhooks:

Example: Complete Multi-Tenant Implementation

Next Steps

Instances

Deep dive into instance management

Authentication

Secure your multi-tenant API

Webhooks

Configure per-tenant webhooks

API Reference

Explore all API endpoints