Un cliente, tres facturas, tres journeys

Ana tiene tres facturas pendientes contigo: $1,250, $480 y $2,100. Cada una debería recibir sus propios recordatorios en su propio tiempo, y cuando pague la de $480, ese recordatorio debería detenerse mientras los otros dos siguen.

Hasta ahora un journey no podía hacer eso. Un journey corría una vez por persona: mientras la corrida de Ana por su primera factura estaba activa, el evento de su segunda factura se descartaba. Y un evento de salida como invoice_paid terminaba la única corrida que tenía, sin importar de qué factura se tratara.

Identifica el journey por factura

Un journey que se dispara con un evento ahora puede definir una llave de corrida: la propiedad del evento que identifica una corrida. En el editor, abre el disparador, elige el evento (invoice_created) y escribe la propiedad en Una corrida por (invoice_id). Por API o MCP es parallelRunsBy: "invoice_id" en journeys_set_trigger.

A partir de ahí, cada invoice_id distinto inicia su propia corrida para la misma persona, y cada corrida lleva los datos de su propio evento a sus mensajes: el monto de esa factura, la liga de pago de esa factura.

Envía un evento por factura

Cada factura es una llamada al endpoint de eventos:

curl -X POST "$BASE/events" \
  -H "Authorization: Bearer $BOOM_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "invoice_created",
    "externalId": "inv_1057_created",
    "personExternalId": "ana_torres",
    "properties": { "invoice_id": "1057", "amount": 480, "pay_url": "https://pay.example.com/1057" }
  }'

Envía la misma llamada para la 1042 y la 1063, y Ana queda en tres corridas a la vez. Aquí importan algunos detalles:

• Usa el endpoint de un solo evento. El registro de eventos en lote se trata como carga histórica y no inicia journeys.
• externalId es la llave de idempotencia. Reenviar el mismo devuelve created: false en lugar de un duplicado.
• La llave de corrida tiene que estar en el primer nivel de properties (invoice_id, no invoice.id). Un evento que no la trae se rechaza en lugar de inscribirse, así que ningún recordatorio sale con el monto en blanco.
• Un valor corre una sola vez. Un invoice_created reintentado o repetido para la 1057 no puede reiniciar una secuencia que ya terminó.

Cancela solo la factura que se pagó

Agrega invoice_paid a las Condiciones de cancelación del journey (metadata.cancelOnEvents por API). En un journey con llave de corrida, el evento de salida se empata con esa misma llave, así que cuando Ana paga la factura 1057 envías:

curl -X POST "$BASE/events" \
  -H "Authorization: Bearer $BOOM_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "invoice_paid",
    "externalId": "inv_1057_paid",
    "personExternalId": "ana_torres",
    "properties": { "invoice_id": "1057" }
  }'

Esa corrida termina. Las de la 1042 y la 1063 ni se enteran. Empatar por la llave tiene dos consecuencias:

• Un evento de salida sin invoice_id no detiene nada. Parece un bug y es intencional: la alternativa es detener todas las corridas de la persona.
• No puedes desactivar el empate en un journey con llave. matchRunKey: false se rechaza al publicar, porque un pago cancelaría también las otras facturas de la persona.

Protégete de la carrera

El evento que dispara y el evento de salida se procesan por separado. Si Ana paga segundos después de que se crea la factura, invoice_paid puede llegar antes de que exista la corrida que debería detener, y la corrida igual empieza.

Así que no dependas de que el evento de salida llegue primero. Pon un paso de Decisión antes de cada envío que revise si la factura sigue pendiente. El evento de salida termina la corrida antes en el caso común, y la decisión cubre el caso raro.

El journey

1. Envía la factura, con el monto y la liga del evento.
2. Espera a un día hábil, no antes de las 9:00. Nadie recibe un recordatorio de pago un domingo a las 6 de la mañana.
3. Decisión: ¿sigue sin pagarse?
4. Envía el recordatorio.

Un journey con llave solo puede enviar. No hay Esperar respuesta ni conversación con IA, porque una respuesta es de la persona, no de una corrida: un "ok, gracias" sobre la primera factura liberaría los recordatorios de las tres. Las corridas también empiezan solo con el evento; agregar a alguien a mano o desde un segmento se rechaza, porque no hay factura de la cual tomar los datos.

Los journeys sin llave de corrida funcionan exactamente igual que antes.

Relaciona las corridas con tu sistema

Cada corrida reporta el externalId de su disparador en los webhooks de journeys, así que cuando llega journey_run.started o journey_run.ended puedes ligarlo a inv_1057_created sin guardar nada nuestro.

Las corridas en paralelo se activan por organización. Si no ves Una corrida por en el disparador, pídeselo a tu contacto en Boom. La referencia completa está en nuestra documentación.