Flujos comunes¶
Recetas end-to-end combinando varios endpoints.
Provisión + primer pairing¶
POST /api/instances { name, events_webhook_url, inbox_id, owner_tag? }
↓ event: qr_generated → events_webhook_url
GET /api/instances/:name/qr (PNG, mostrar al usuario)
↓ usuario escanea
↓ event: paired → events_webhook_url
↓ event: connected → events_webhook_url
↓ ya puedes enviar mensajes
Alternativa: GET /api/instances/:name/wait-ready?timeout=120 bloquea
hasta ready sin necesidad de polling.
Enviar un mensaje¶
POST /api/instances/:name/webhook { message_type:"outgoing", content, ... }
→ 200 {status:"sent"} si la instancia está conectada
→ 202 {status:"queued", ...} si está reconectando (outbox)
Sesión perdida (logged_out)¶
event: logged_out → events_webhook_url
POST /api/instances/:name/refresh-qr
↓ event: qr_generated → events_webhook_url
GET /api/instances/:name/qr (PNG nuevo)
↓ usuario escanea
↓ event: paired / connected
Borrado limpio¶
POST /api/instances/:name/logout (invalida server-side)
DELETE /api/instances/:name (borra bridge_instance row + audit)
Billing al cierre de mes¶
Investigar un strike¶
GET /api/audit?instance=whatsapp-main&limit=200
↓ buscar entradas anteriores al evento "strike"
GET /api/instances/whatsapp-main/usage?from=...&to=...
↓ ver pico de envíos
GET /api/instances/whatsapp-main/ban-risk
↓ ver snapshot actual
Glosario¶
Flujo end-to-end: secuencia completa de llamadas API necesarias para completar un caso de uso (provision, send, recovery, billing, etc.).
Provisión + pairing: secuencia inicial donde se crea una instancia y el usuario escanea el QR para vincular su número WhatsApp. Solo se hace la primera vez.
Recovery flow (sesión perdida): secuencia para regenerar el pairing
cuando WhatsApp invalidó la sesión server-side (logged_out). Requiere
nuevo escaneo del usuario.
Borrado limpio: secuencia logout + DELETE. El logout invalida
la sesión en Meta servers; el DELETE borra la fila de
bridge_instance. El audit log conserva la traza.
Billing al cierre de mes: query típica para facturación —
/api/usage/summary con el mes actual, agrupado por owner_tag.
Forensics: investigación post-incidente combinando /api/audit
(quién hizo qué), /api/usage (volumen de actividad) y /api/ban-risk
(estado actual de las señales).