Envía eventos desde tu backend con la clave secreta, y los límites de ingesta que aplican.

Hay eventos que no deberían venir de un navegador: pagos que se concretan de forma asíncrona, renovaciones de suscripción, trabajos en segundo plano, cualquier cosa en la que el usuario no puede estar presente. Esos van por el endpoint de ingesta del servidor con tu clave secreta.

Clave pública vs clave secreta

	Clave pública	Clave secreta
Formato	`lp_pub_` + 22 caracteres base58	`lp_sec_` + 43 caracteres base58
Para qué sirve	`init()` del SDK del navegador	Ingesta desde el servidor
Exposición	Diseñada para viajar en el código del cliente: es segura y esperada	Nunca en código del navegador. Léela desde una variable de entorno
Almacenamiento	Se guarda en texto plano, visible cuando quieras en Configuración → Instalación	Solo se guarda un hash — se muestra exactamente una vez, al crear el proyecto o al rotar la clave

Como solo se guarda un hash de la clave secreta, LaunchPulse no puede volver a mostrártela. Si la pierdes, rota la clave en Configuración del proyecto — lo que invalida la anterior — y guarda el valor nuevo de inmediato.

Usa el nombre de variable de entorno LAUNCHPULSE_SECRET. Ese es el nombre que el prompt de agentes IA de la app le indica a los agentes de código, así que respetarlo hace que un agente que arme tu integración lo encuentre.

El endpoint

POST https://collector.launchpulse.dev/v1/events
Authorization: Bearer lp_sec_...
Content-Type: application/json

Un evento por petición.

curl -X POST https://collector.launchpulse.dev/v1/events \
  -H "Authorization: Bearer $LAUNCHPULSE_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "event": "subscription_paid",
    "user_id": "user_8f21c",
    "properties": {
      "$revenue": 49.99,
      "$currency": "USD",
      "plan": "annual"
    }
  }'

En Node, con fetch:

async function sendToLaunchPulse(event) {
  const res = await fetch("https://collector.launchpulse.dev/v1/events", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.LAUNCHPULSE_SECRET}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify(event),
  });

  if (!res.ok) {
    console.error("LaunchPulse ingest failed", res.status);
  }
}

await sendToLaunchPulse({
  event: "trial_converted",
  user_id: user.id,
  properties: { plan: "pro", seats: 3 },
});

Usa el mismo user_id que tu código de navegador le pasa a identify(). El mismo id en ambos lados significa un solo actor. Ids distintos significan la misma persona contada dos veces.

El endpoint del navegador, para comparar

El SDK envía lotes a un endpoint distinto, con la clave pública en el cuerpo:

POST https://collector.launchpulse.dev/e
{ "k": "lp_pub_...", "events": [ ... ] }

Normalmente no lo llamas tú: eso es lo que hace el SDK. Los detalles están en la Referencia del SDK.

ingest_source

Los eventos enviados desde el servidor quedan marcados con ingest_source: 'server'. Los del navegador con 'browser'. Puedes filtrar por ese campo en el registro de eventos, lo que sirve para verificar si una integración realmente está disparando.

Límites

Límite	Valor
Tamaño del cuerpo de la petición	256 KB
Máximo de eventos por petición	500 (si no, HTTP 413)
Límite de tasa	6000/min por clave pública, 6000/min por IP (si no, HTTP 429)

Los límites de propiedades son los mismos que en el SDK del navegador: 64 propiedades, claves de 64 caracteres, valores string de 1024 caracteres, profundidad 3, 32 entradas por arreglo u objeto, 8192 bytes serializados. Violar cualquiera rechaza el evento. La tabla completa está en la Referencia del SDK.

$revenue y $currency funcionan exactamente igual que en el navegador. Cualquier otra clave de propiedad con $ rechaza el evento. Mira Medir ingresos.

Dos comportamientos que te van a confundir si no los conoces

Un 2xx no significa que tu clave funcione

Las claves desconocidas, revocadas y pausadas reciben todas una respuesta 2xx uniforme. La API deliberadamente no revela si una clave existe ni en qué estado está: es una medida contra la enumeración, para que nadie pueda sondear tus claves mirando códigos de estado.

La consecuencia para ti: un 200 no prueba que tu clave sea válida. Si estás armando una integración y quieres confirmación, usa la pantalla de prueba del onboarding, o revisa el registro de eventos. Que los datos aparezcan en el registro es la única prueba.

Los proyectos pausados se comportan igual: los eventos se aceptan y se descartan.

Las marcas de tiempo se recortan

Si envías una marca de tiempo del cliente, se recorta a la ventana [hora de recepción del servidor − 5 minutos, hora de recepción del servidor]. La hora de recepción del servidor es la que manda.

Esto significa que no puedes cargar historial retroactivo por este endpoint, ni enviar eventos con fecha futura. Un trabajo en cola que reintenta una hora después va a caer en la hora del reintento, no en la original. Si el momento exacto importa, envía los eventos a medida que ocurren en lugar de acumularlos en una corrida nocturna.

Cuándo enviar desde el servidor

Ingresos. El pago se concreta en tu backend, no en una página de gracias que el usuario puede recargar. Mira Medir ingresos.
Renovaciones y bajas. Ahí no hay navegador involucrado.
Cualquier cosa que un usuario no debería poder falsear. Los eventos del navegador vienen de un cliente que no controlas.
Eventos de trabajos en segundo plano: una exportación que termina, una importación que se completa, un reporte programado que sale.

Deja las vistas de página y las interacciones dentro de la app en el navegador. Ahí el SDK ya se encarga de identidad, sesiones y atribución, y reproducir eso del lado del servidor es trabajo sin ganancia.

Cómo cuidar la clave

Variable de entorno, nunca un archivo commiteado. LAUNCHPULSE_SECRET.
Nunca en un bundle, en un componente cliente, ni en nada que lleve NEXT_PUBLIC_.
Rótala en Configuración del proyecto si alguna vez termina en un lugar público. La rotación invalida la clave anterior de inmediato.

Más en Seguridad.

Eventos desde el servidor