# Declarar eventos (/es/guides/declaring-events)

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:

```bash
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](/es/guides/custom-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.