Skip to main content
Traducción. Autoritativo: ../../standards/events.md.

​
Envelope (todo evento, sin excepciones)

{ id: uuidv7, name, tenant_id, occurred_at, correlation_id, causation_id, actor: {type: user|member|api_key|system, id}, version: int, payload }
  • El correlation_id nace en el punto de entrada (llamada a track, comando de consola, job de cron) y se propaga por: evento de dominio → efecto de regla → job de notificación → envío → historial de estados → webhook saliente. Toda línea de log en BetterStack incluye tenant_id + correlation_id.
  • causation_id = id del evento o comando que causó directamente este (reconstrucción de la cadena).

​
Nombres

{context}.{entity}.{verbo_pasado} — por ejemplo core.contact.created, loyalty.points.earned, messaging.message.delivered. Verbos en pasado. Solo inglés.

​
Catálogo v1 (emitidos → outbox → 6 consumidores; todos disponibles como webhooks salientes)

  • core: contact.created|updated|merged · consent.granted|revoked · event.tracked · segment.entered|exited
  • loyalty: points.earned|redeemed|expired|adjusted|revoked · points.expiring_soon · coupon.issued|redeemed|expired · referral.link_created|converted · tier.upgraded|downgraded
  • messaging: campaign.triggered · message.sent|delivered|opened|clicked|bounced|complained
  • crm: note.created · activity.completed · list.membership_changed

​
Reglas

  • Los eventos se emiten ÚNICAMENTE por el outbox transaccional, dentro de la transacción del comando. La publicación directa está prohibida.
  • Los payloads son delgados: ids más los campos desnormalizados mínimos que los consumidores necesitan; el resto lo consultan ellos. Sin PII más allá de contact_id salvo que el contrato del consumidor lo exija (webhooks: inclusión de PII configurable, apagada por defecto).
  • Los cambios de esquema de evento son solo aditivos dentro de una versión; un cambio que rompe implica version+1 y ambas versiones emitidas durante la ventana de deprecación.