Procedencia

Nada de lo que el portal muestra como referencia ni como catálogo de eventos se escribe a mano: sale de instantáneas de la especificación que cada dominio genera desde su código. El portal no lee las especificaciones en vivo: las copia, las rotula con el SHA del dominio y la hora, y se regenera después de cada cambio de rutas. (C7)

• SHA es el HEAD del árbol de trabajo del dominio al tomar la instantánea. Si el árbol tenía un merge en curso o cambios sin commitear, lo documentado puede no coincidir exactamente con ese commit.
• Catálogo de eventos: cada dominio expone GET /api/v1/webhooks/events, que pide una clave. Si la instantánea se tomó sin clave, el catálogo sale de la sección webhooks de la especificación (o, en su defecto, del esquema de respuesta del catálogo) y lo dice en la página de eventos. Por la URL base, esa ruta llega a accounts, cuyo catálogo lista los eventos de las tres áreas con su area: el portal atribuye cada evento a su área y, si el área lo declara en su propia instantánea, usa esa declaración.
• Si un dominio no responde o responde algo que no es una especificación válida, se conserva la instantánea anterior.

La especificación unificadaCopiar el enlace a esta sección

specs/funnelchat.json junta en una sola especificación OpenAPI 3.1 las operaciones de las tres instantáneas, con la URL base única y las rutas completas: 237 operaciones. Sale de las mismas instantáneas, con los nombres, las descripciones y las notas de v0 del portal; en x-fc-sources dice de qué SHA salió cada parte.

Qué área atiende cada ruta no lo decide el portal: lo decide el borde de la API, que reparte las llamadas a la URL base según el primer segmento de la ruta. Cada operación lo dice en x-fc-domain. Una ruta que figura en la instantánea de un área pero que el borde manda a otra no entra en la unificada (sigue en la especificación de su área) y queda listada en x-fc-excluded-routes. En esta versión:

• GET /api/v1/webhooks/{webhook}/deliveries (instantánea de conversations): el borde la manda a accounts.
• GET /api/v1/webhooks/events (instantánea de conversations): el borde la manda a accounts.
• GET, POST /api/v1/webhooks (instantánea de conversations): el borde la manda a accounts.
• GET, PUT, DELETE /api/v1/webhooks/{webhook} (instantánea de conversations): el borde la manda a accounts.
• POST /api/v1/webhooks/{webhook}/rotate-secret (instantánea de conversations): el borde la manda a accounts.
• POST /api/v1/webhooks/{webhook}/test (instantánea de conversations): el borde la manda a accounts.
• GET /api/v1/forms/templates (instantánea de conversations): el borde no la enruta.
• GET, POST /api/v1/forms (instantánea de conversations): el borde no la enruta.
• GET /api/v1/forms/families/{familyId}/metrics (instantánea de conversations): el borde no la enruta.
• GET /api/v1/forms/families/{familyId}/responses (instantánea de conversations): el borde no la enruta.
• GET /api/v1/forms/families/{familyId}/responses/{runId} (instantánea de conversations): el borde no la enruta.
• GET /api/v1/forms/families/{familyId}/versions (instantánea de conversations): el borde no la enruta.
• GET /api/v1/forms/families/{familyId}/definition (instantánea de conversations): el borde no la enruta.
• GET, PUT, DELETE /api/v1/forms/{id} (instantánea de conversations): el borde no la enruta.
• GET, POST /api/v1/forms/{id}/numbers (instantánea de conversations): el borde no la enruta.
• POST /api/v1/forms/{id}/versions (instantánea de conversations): el borde no la enruta.
• POST /api/v1/forms/{id}/sync (instantánea de conversations): el borde no la enruta.
• POST /api/v1/forms/{id}/publish (instantánea de conversations): el borde no la enruta.
• DELETE /api/v1/forms/{id}/numbers/{deviceId} (instantánea de conversations): el borde no la enruta.
• POST /api/v1/forms/{id}/numbers/retry (instantánea de conversations): el borde no la enruta.
• GET, POST /api/v1/webhooks (instantánea de communities): el borde la manda a accounts.
• GET /api/v1/webhooks/events (instantánea de communities): el borde la manda a accounts.
• GET, PUT, DELETE /api/v1/webhooks/{webhook} (instantánea de communities): el borde la manda a accounts.
• POST /api/v1/webhooks/{webhook}/rotate-secret (instantánea de communities): el borde la manda a accounts.
• POST /api/v1/webhooks/{webhook}/test (instantánea de communities): el borde la manda a accounts.
• GET /api/v1/webhooks/{webhook}/deliveries (instantánea de communities): el borde la manda a accounts.

Si dos áreas usan el mismo nombre para cosas distintas (un esquema, una respuesta de error), en la unificada llevan el nombre del área delante (Conversations…, Communities…, Accounts…); lo que es igual queda una sola vez. Cada generación del sitio verifica que el archivo sea OpenAPI 3.1 válido y que cada ruta vaya al área que dice el borde.

Qué se escribe a manoCopiar el enlace a esta sección

• Los textos de contexto: inicio, guía rápida, autenticación, webhooks y la introducción de eventos y referencia. Salen del contrato de la iniciativa (C1, C3 v4, C6, C7 y las enmiendas del 04-10), del contrato del registro de llamadas (1019: la cabecera X-Request-Id y los errores propios de la entrada), de las decisiones del piloto (D5–D23) y de las del 04-10 (Q14–Q36). Los topes diarios (solo en accounts y communities) salen de la Q20 del 14-10.
• La orientación del portal —armá tu propio Funnelchat, las piezas primero y las funciones de Funnelchat aparte— y las páginas de piezas, «Armá tu propio flujo» y «Reglas de WhatsApp». Salen del principio y las decisiones del 14-10 (Q1–Q20) y del contrato de esa etapa. El envío con clave, las reglas de WhatsApp y sus errores, el ritmo por número, message.status_changed y capabilities están en las instantáneas del 22-10 y las páginas siguen lo que dicen. El portal solo muestra lo que un integrador puede usar hoy.
• Las reglas de disponibilidad en v0 por dominio y el catálogo v0 de eventos planificados (DECISIONES-2026-10-04, Q34).
• Los snippets de verificación de firma, probados en cada generación del sitio. Último resultado de tests/test_firmas.py (2026-10-22 20:53 (+00:00)): pasó — Python 3.12.15, Node v24.21.0, PHP 8.3.6.

Cómo se regeneraCopiar el enlace a esta sección

python3 scripts/snapshot.py      # toma las instantáneas (FC_API_KEY opcional, para el catálogo de eventos)
npm run build                    # genera páginas y specs (scripts/build.py, con el test de firmas), verifica la unificada, la referencia por endpoint y el sitio

La referencia por endpoint la genera Fumadocs OpenAPI 12.3.0 a partir de las especificaciones anotadas; el sitio se publica como archivos estáticos.