Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/DevMauricio03/n8n-whatsapp-ai-agent/llms.txt

Use this file to discover all available pages before exploring further.

After you import the WhatsApp AI Agent workflow into n8n, every node that calls an external service must be manually linked to a saved credential. n8n stores these credentials encrypted in the database (protected by N8N_ENCRYPTION_KEY), which keeps API keys out of the workflow JSON and out of version control. No real tokens, passwords, or private keys should ever be committed to the repository — not even in workflow exports.

The Golden Rule: Never Commit Secrets

The project enforces a strict boundary between configuration examples and live secrets:
  • .env.example contains only placeholder names and fictional values (e.g. CHANGE_ME, example.com). It is safe to commit and serves as documentation for what variables exist.
  • .env is listed in .gitignore and must never be committed. It holds all real secrets.
  • Workflow JSON exports must not contain embedded tokens. Always clear credential links before exporting and re-assign them after import using n8n’s credential store.
The original version of this workflow repository contained a real WhatsApp Business Cloud token committed directly in the workflow JSON. That token must be considered compromised regardless of whether the repository is public or private. Follow the steps in the Compromised Token section to revoke and replace it.

Required n8n Credentials

Create each of the following credentials in n8n under Settings → Credentials → New Credential before activating the workflow.
CredentialType in n8nConfiguration
OpenAIOpenAI APIAPI key from platform.openai.com and the authorized project ID
PostgreSQLPostgresHost postgres, port 5432, database agent, user and password from .env
RedisRedisHost redis, port 6379, password matching REDIS_PASSWORD in .env
WhatsApp Business CloudWhatsApp Business CloudPermanent system user token and the WHATSAPP_PHONE_NUMBER_ID value
Google Drive OAuth2Google Drive OAuth2 APIOAuth 2.0 client with the minimum drive.readonly scope for the source file
HTTP Header AuthHeader AuthHeader name Authorization, value Bearer <WHATSAPP_TOKEN> — used by media-download nodes
The PostgreSQL agent database is created automatically by the init script at docker/initdb/01-create-databases.sql. The bd_clientes table used by the agent is created by docker/initdb/02-agent-schema.sql when the stack first starts.

Assigning Credentials After Import

1

Open the workflow in the n8n editor

Navigate to Workflows in the n8n sidebar and open the imported WhatsApp AI Agent workflow.
2

Identify nodes with missing credentials

Nodes that lack an assigned credential display an orange warning indicator. Click each one to open its settings panel.
3

Select the matching credential

In the node settings panel, locate the credential dropdown and choose the credential you created for that service. If none appears, click Create new credential to add it inline.
4

Repeat for every node

Work through all OpenAI, PostgreSQL, Redis, WhatsApp Business Cloud, Google Drive, and HTTP Header Auth nodes until no orange indicators remain.
5

Save and activate the workflow

Click Save and then toggle the workflow to Active. The WhatsApp webhook will begin receiving messages once the workflow is active and Caddy is routing traffic correctly.

HTTP Header Auth for Media Downloads

WhatsApp media download requests require a valid bearer token in the Authorization header. Rather than hardcoding the token in individual HTTP Request nodes, store it as an HTTP Header Auth credential so it is encrypted at rest and easy to rotate. Create the credential with the following values:
Name:   Authorization
Value:  Bearer <your-whatsapp-system-user-token>
Then assign this credential to every HTTP Request node in the workflow that fetches media from graph.facebook.com. When you rotate the token, you only need to update the single credential record — all nodes that reference it are updated automatically.

Secret Rotation

Rotate credentials on a regular schedule or whenever a team member with access leaves the project. Follow these steps for each secret:
  1. Generate a new credential using the issuing platform (Meta Developer console, OpenAI dashboard, Google Cloud console, etc.) or with openssl rand -hex 32 for local secrets.
  2. Update the value in the provider (e.g. activate the new token in Meta) and in n8n’s credential store or in .env, depending on where the secret is used.
  3. Restart only the services that depend on the changed secret. For .env secrets, use:
    docker compose --env-file .env -f docker/docker-compose.yml up -d --no-deps <service-name>
    
  4. Test reception and sending of WhatsApp messages, and verify that all workflow nodes execute without authentication errors.
  5. Revoke the old credential through the issuing platform to prevent any residual use.
  6. Record the rotation: date, the person who performed it, and whether all tests passed. Keep this log outside the repository.

Compromised Token

If a token or secret has been exposed — through a public repository, logs, or any unintended disclosure — treat it as compromised immediately and take the following actions:
1

Revoke the token immediately

Log in to the issuing platform (e.g. Meta Developer console for WhatsApp tokens, OpenAI dashboard for API keys) and revoke or delete the exposed credential right away, before completing any other steps.
2

Review access logs

Check the platform’s usage logs for any API calls made with the compromised token that were not initiated by your system. Document anything suspicious.
3

Generate a replacement credential

Issue a new token or key from the provider and store it immediately in n8n’s credential store or in .env — never in a file tracked by Git.
4

Update and restart affected services

Assign the new credential in n8n and restart any services that use the secret via .env. Verify that the workflow is fully operational with the new credential.
5

Consider rewriting Git history

If the token was committed to the Git repository, decide — with a full backup in place — whether to rewrite history using git filter-repo or BFG Repo Cleaner. Be aware that rewriting history changes all commit identifiers and requires every existing clone to be updated or replaced.
6

Record the incident

Document the timeline, affected systems, actions taken, and any evidence of unauthorized use. Keep this record outside the repository.

Build docs developers (and LLMs) love