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.

The acceptance test plan defines the 22 scenarios that must be verified before any version of the n8n WhatsApp AI Agent is considered production-ready. All tests must be executed using fictitious data and a dedicated test WhatsApp number — never against the live business number with real customers. For each test case, record the date the test was run, the stack version under test, the actual result observed, and the evidence collected (typically a screenshot or log excerpt). This record is part of the release documentation and must be retained alongside the release notes.

Test cases

The table below lists all 22 acceptance test cases organised by area: messaging behaviour, AI responses, human handoff, business hours, data synchronisation, security, operations, and backup.
IDScenarioExpected result
MSG-01Send a greeting messageA brief response in Spanish
MSG-02Send three messages in rapid successionA single response that groups all the content
MSG-03Send a valid audio messageCorrect transcription and response
MSG-04Send an invalid audio messageControlled error with no invented response
MSG-05Send an image or stickerIgnored or handled according to the defined policy
AI-01Ask about a serviceGuidance without inventing information
AI-02Ask for general pricingThe correct resource is sent
AI-03Provide an existing case reference numberOnly authorised information is returned
AI-04Provide a non-existent case reference numberThe contact is informed that no record was found
AI-05Ask an out-of-scope questionThe agent limits its response to its defined scope
HH-01A human agent responds in ChatwootThe Redis handoff key is created
HH-02The customer writes during an active handoffThe AI does not respond
HH-03The handoff TTL expiresAutomatic AI mode resumes
HH-04Redis is unavailableThe automation fails safely without crashing
TIME-01Message received during business hoursThe AI executes normally
TIME-02Message received outside business hoursAn out-of-hours notice is sent; the AI does not execute
TIME-03Message received on a weekendThe out-of-hours policy is applied
DATA-01Update the source XLSX fileThe bd_clientes table is updated in the agent database
DATA-02XLSX contains a duplicate row for an existing referenceThe existing record is updated, not duplicated
SEC-01Webhook receives an incomplete payloadNo secrets are leaked and the overall flow does not break
OPS-01All services are restartedData and configuration persist correctly after restart
BAK-01Restore backup in an isolated environmentAll services and data are successfully recovered

Minimum pre-release test set

Before every release — including minor configuration changes and pricing updates — execute at least these nine test cases and confirm they all pass. Do not deploy to production with any of these in a failing state:
  • MSG-01 — basic greeting and response
  • MSG-02 — message grouping behaviour
  • AI-03 — case reference lookup with a known record
  • HH-01 — human handoff Redis key creation
  • HH-02 — AI silence during active handoff
  • TIME-01 — AI executes during business hours
  • TIME-02 — out-of-hours message sent outside business hours
  • DATA-01 — XLSX sync updates the database
  • OPS-01 — data and configuration persist through a restart

Test evidence template

For each test case, retain a record using the following structure. Store completed records in your team’s release documentation alongside the version they correspond to.
ID:
Fecha:
Entorno:
Versión:
Datos usados:
Resultado esperado:
Resultado obtenido:
Evidencia:
Responsable:
Before sharing any test evidence — screenshots, log excerpts, or screen recordings — mask all personally identifiable and sensitive content. This includes customer phone numbers, names, email addresses, API tokens, webhook secrets, and any message content that could identify a real person. Use an image editor or a redaction tool to apply opaque blocks over sensitive fields before the file leaves your local machine.

Build docs developers (and LLMs) love