Eventos

Un evento es un registro de que ha pasado algo en tu espacio de trabajo: se ha entregado un email, se ha hecho clic en un enlace, ha llegado un mensaje a tu subdominio de entrada, se ha creado un contacto. Emailit guarda todos los eventos, los muestra en el panel y construye a partir de ellos cada petición de webhook. Esta página explica cómo consultar los eventos y leerlos con la API.

Qué contiene un evento

{
  "object": "event",
  "id": "evt_2xGk7Nq1VbD5sR8tLmW3eYhC6aP",
  "type": "email.delivered",
  "data": {
    "object": {
      "id": "em_2xGk7Lr3XcB8pQ1wYzK4dTfG9hJ",
      "object": "email",
      "from": "billing@acme.com",
      "to": "ada@example.com",
      "subject": "Your receipt #1042",
      "status": "delivered",
      "meta": { "order_id": "1042" },
      "updated_at": "2026-10-01T09:14:03.512000+00:00",
      "created_at": "2026-10-01T09:14:01.207000+00:00"
    }
  },
  "created_at": "2026-10-01T09:14:03.540000+00:00"
}

Eventos y webhooks

Los eventos son el origen de las peticiones de webhook. Cuando Emailit registra un evento, pone en cola una petición para cada webhook activado que está suscrito a ese tipo de evento y cuyo filtro de payload coincide. El evento se guarda tanto si lo recibe algún webhook como si no.

Esto tiene dos consecuencias:

• Un webhook solo recibe los eventos que ocurren mientras existe y está activado. Los eventos registrados mientras un webhook estaba desactivado, o antes de que se creara, no se le envían después.
• Puedes usar la lista de eventos para cubrir huecos. Después de una caída o de un periodo de desactivación, lee con la API los eventos de ese intervalo de tiempo y procesa los que tu webhook no recibió. Elimina los duplicados por ID de evento, que es el mismo ID evt_ que los webhooks usan como event_id.

Consultar los eventos en el panel

Ve a Email API›Events. La tabla muestra el Event type, el ID y la hora de Created de cada evento, de más reciente a más antiguo.

• Por defecto, la página muestra los últimos 2 días. Añade un filtro Created para ir más atrás, dentro de tu periodo de retención.
• Filtra por Type para ver un solo tipo de evento, por ejemplo solo email.bounced.
• Selecciona un evento para ver su hora de Created, su Type y el Payload completo en JSON, con un botón para copiarlo.

Leer los eventos con la API

Los dos endpoints necesitan una clave de API con Full Access.

Listar eventos

Listar eventos devuelve los eventos de más reciente a más antiguo.

curl -G https://api.emailit.com/v2/events \
  -H "Authorization: Bearer $EMAILIT_API_KEY" \
  --data-urlencode "type=email.bounced,email.complained" \
  --data-urlencode "created_at.after=2026-09-28T00:00:00Z" \
  --data-urlencode "include_data=true"

{
  "data": [
    {
      "object": "event",
      "id": "evt_2xGkB3n8WqZ5cT1vRmK7pLsD4hY",
      "type": "email.bounced",
      "data": { "object": { "id": "em_2xGkA9m1PdX6bR3sQnJ8tKfW2eV", "object": "email", "status": "bounced" } },
      "created_at": "2026-09-30T17:02:41.118000+00:00"
    }
  ],
  "next_page_url": "/v2/events?page=2&limit=100&type=email.bounced%2Cemail.complained&include_data=true",
  "previous_page_url": null
}

Dos límites mantienen la rapidez de este endpoint:

• Ventana por defecto. Sin un filtro created_at, la lista cubre los últimos 2 días. Añade created_at.after para leer eventos más antiguos.
• Profundidad de página. El desplazamiento, (page - 1) × limit, no puede superar 2500. Las páginas más profundas devuelven 422 con el código events_offset_too_large. Acota la petición con type o con un intervalo de created_at en lugar de seguir paginando.

Obtener un evento

Obtener un evento devuelve un evento por su ID evt_, siempre con data.

curl https://api.emailit.com/v2/events/evt_2xGk7Nq1VbD5sR8tLmW3eYhC6aP \
  -H "Authorization: Bearer $EMAILIT_API_KEY"

Conciliar los eventos de webhook perdidos

1. Elige el intervalo. Anota cuándo empezó a fallar tu endpoint o cuándo se desactivó el webhook, y cuándo se solucionó.

2. Lista los eventos. Llama a GET /v2/events con created_at.after y created_at.before ajustados a ese intervalo, los valores de type que gestiona tu webhook e include_data=true. Sigue next_page_url hasta que sea null. Si te encuentras con events_offset_too_large, divide el intervalo en tramos más cortos.

3. Procesa lo que no hayas visto. Omite los eventos cuyo ID ya tengas guardado como procesado, y gestiona el resto con el mismo código que usa tu webhook.

Para las peticiones que se pusieron en cola pero fallaron, es más sencillo usar Retry failed en el webhook, siempre que los fallos tengan menos de 7 días.

Retención

Los eventos siguen el periodo de retención de Logs, igual que los registros de peticiones y las peticiones de webhook:

Ver también