Declarar eventos

Ponle nombre a un evento antes de que nada lo envíe, para poder construir el flujo primero

Puedes ponerle nombre a un evento en Configuración → Datos → Eventos antes de que tu aplicación haya enviado ninguno. El nombre queda disponible en flujos y segmentos de inmediato.

Por qué querrías hacerlo

El disparador de un flujo es un nombre de evento, que se empareja cuando el evento llega. Eso siempre ha significado que podías construir un flujo para un evento que aún no existe — pero la lista de sugerencias sólo mostraba eventos ya recibidos, así que el nombre era invisible hasta que algo lo disparaba. La gente lo esquivaba enviando un evento de prueba sólo para que el nombre apareciera.

Declarar elimina ese rodeo. Construye la automatización esta mañana y despliega el código que envía el evento esta tarde.

Qué hace y qué no

Declarar un evento hace que su nombre sea visible y esté documentado. Nada más.

Aparece en los selectores de flujos y segmentos de inmediato.
Lleva un nombre visible y una descripción, como cualquier otro evento.
La lista lo muestra como aún no recibido hasta que llegue el primero — algo útil de ver por sí solo. Un evento que declaraste hace tres semanas y que sigue sin llegar es una integración que nunca se terminó.

No se rechaza nada. Los eventos que nunca declaraste se reciben exactamente igual que antes. Declarar no es un registro en el que los eventos tengan que estar: no valida nada y no cambia cómo emparejan los flujos ni los segmentos.

Cómo enviarlo

Utiliza la clave pública del mismo proyecto y el nombre exacto del evento. Este ejemplo deja al contacto explícitamente sin suscripción; no sobrescribas un consentimiento existente al enviar eventos habituales:

curl -X POST https://api.bitelio.com/v1/track \
  -H "Authorization: Bearer pk_TU_CLAVE_PUBLICA" \
  -H "Content-Type: application/json" \
  -d '{
    "event": "user.signup",
    "email": "cliente@ejemplo.com",
    "subscribed": false,
    "data": { "plan": "pro" }
  }'

El email es obligatorio. Es lo que atribuye el evento a un contacto, y es la primera razón por la que suele fallar el primer intento.

Elige la autenticación correcta

/v1/track acepta solo la clave pública (pk_*), no una clave secreta. Envía eventos de negocio desde tu backend después de validar el origen, pero no trates la clave pública como prueba de una compra ni de la identidad de quien llama. Cualquiera que la tenga puede enviar eventos para un email y activar los flujos correspondientes.

Mantén las claves secretas en tu servidor para los endpoints que las requieren, como la gestión de contactos. Nunca utilices un evento recibido por el endpoint público para autorizar reembolsos, recompensas o accesos. Para una integración completa de contactos y compras, consulta Conectar otro CMS.

Quitar una declaración

Borrar la declaración de un evento que ya se ha recibido no elimina el evento. Vuelve a ser un evento normal: sigue en la lista, sigue siendo seleccionable, sólo que sin el nombre visible ni la descripción que le pusiste.

Sólo desaparece del todo un evento que se declaró y nunca llegó a recibirse — una vez borrada la declaración, no queda nada que conozca el nombre.

Ninguna de las dos cosas borra datos de eventos. Eso es una acción aparte en la misma pantalla.