Saltar al contenido
Tickeep
Índice de la API

Referencia: asistentes e informes

El listado de personas de tu organización y el informe de recaudación, con el corte por canal ya calculado.

Última actualización: 23 de agosto de 2026

Asistentes

Las personas que han comprado, con su historial acumulado.

1 endpoint
GET/attendeesListar asistentes de la organización

Informes

Recaudación de una sala, con comparativa y serie por día.

1 endpoint
GET/reports/salesvenueId obligatorioConsultar la recaudación de una sala

Asistentes

GET/attendees

Las personas que han comprado en tu organización, con sus datos de contacto.

Necesita el permiso customers:read.

ParámetroValores
emailEmail exacto. Para buscar a una persona concreta
updatedSinceFecha ISO 8601, para sincronización incremental
limit1–100, por defecto 25
cursorEl nextCursor de la página anterior
{
  "data": [
    {
      "id": "6a7400cc33dd44ee55ff6600",
      "email": "ana@ejemplo.com",
      "name": "Ana Ruiz",
      "phone": "600123456",
      "marketingConsent": true,
      "orderCount": 4,
      "totalSpent": { "amount": 14200, "currency": "EUR" },
      "createdAt": "2025-11-03T21:14:02.000Z",
      "updatedAt": "2026-08-23T18:02:11.000Z"
    }
  ],
  "hasMore": false,
  "nextCursor": null
}

Son por organización, no por sala

Este listado no acepta venueId

Quien compra en dos salas de tu organización es una sola persona, con un historial y un total gastado que suman las dos. Trocearlo por sala daría una foto falsa, así que los asistentes viven en la organización.

Ésa es también la razón de que necesite su propio permiso, customers:read, en vez de heredarlo de orders:read: un integrador que solo consulta ventas de una sala no debería recibir de regalo el fichero de compradores completo.

Si tu clave está acotada a una sala, piénsatelo dos veces antes de darle este permiso.

marketingConsent

El consentimiento no es opcional

marketingConsent refleja si esa persona aceptó recibir comunicaciones comerciales. Filtra por él antes de meter a nadie en una lista de envíos. Que alguien te haya comprado una entrada no te autoriza a mandarle publicidad, y la responsabilidad de cumplirlo es de quien manda el email.

const suscribibles = asistentes.filter((a) => a.marketingConsent)

Sincronizar con tu CRM

updatedSince es lo que hace viable una sincronización periódica. La receta entera, con el patrón que no pierde registros, está en sincronizar ventas con tu CRM.

Lo que no está aquí

No se pueden crear, editar ni borrar asistentes por API. Se crean solos con cada venta. Si necesitas corregir un dato, se hace desde el panel.

Informe de ventas

GET/reports/sales

Recaudación de una sala en un periodo, con comparativa y serie temporal.

Necesita el permiso reports:read.

ParámetroObligatorioValores
venueIdSíId de sala
presetNo30d (por defecto) · 90d · year · custom
startCon customFecha AAAA-MM-DD
endCon customFecha AAAA-MM-DD, inclusive
presetPeriodo
30dÚltimos 30 días. Es el valor por defecto
90dÚltimos 90 días
yearAño en curso, desde el 1 de enero
customEl rango que le des en start y end
Las fechas solo se aplican con preset=custom

Si mandas start y end sin preset=custom, se ignoran en silencio y recibirás los últimos 30 días. Es el error más fácil de cometer con este endpoint y no da ningún aviso: comprueba siempre el period que viene en la respuesta.

Los días se cuentan en la zona horaria de la sala, y end es inclusive. Un rango inválido —fechas mal formadas, o start posterior a end— cae también a los últimos 30 días.

venueId es obligatorio

La recaudación se calcula por sala, porque cada una tiene su zona horaria. Un total agregado sobre husos distintos no significa nada: «las ventas del martes» no es lo mismo si una sala está en Madrid y otra en Canarias. Si quieres el total de la organización, pide cada sala y suma tú, sabiendo lo que estás sumando.

curl -G https://app.tickeep.com/api/v1/reports/sales \
  -H "Authorization: Bearer $TICKEEP_API_KEY" \
  --data-urlencode "venueId=$VENUE" \
  --data-urlencode "preset=custom" \
  --data-urlencode "start=2026-08-01" \
  --data-urlencode "end=2026-08-31"

{
  "venueId": "6a42356a296cb2dfe6ba1c7f",
  "timezone": "Europe/Madrid",
  "currency": "EUR",
  "period": {
    "start": "2026-08-01",
    "end": "2026-08-31",
    "label": "Periodo personalizado"
  },
  "summary": {
    "orders": 412,
    "tickets": 968,
    "ticketRevenue": { "amount": 1642000, "currency": "EUR" },
    "vat": { "amount": 344820, "currency": "EUR" },
    "serviceFees": { "amount": 82400, "currency": "EUR" },
    "total": { "amount": 1724400, "currency": "EUR" },
    "averageOrder": { "amount": 4186, "currency": "EUR" },
    "byChannel": {
      "online": { "orders": 380, "tickets": 890, "total": { "amount": 1601000, "currency": "EUR" } },
      "boxOffice": { "orders": 24, "tickets": 58, "total": { "amount": 98400, "currency": "EUR" } },
      "api": { "orders": 8, "tickets": 20, "total": { "amount": 25000, "currency": "EUR" } }
    }
  },
  "previousSummary": { "…": "el mismo bloque, para el periodo anterior" },
  "timeline": [
    { "date": "2026-08-01", "…": "el mismo bloque, para ese día" }
  ]
}

Las tres partes

BloqueQué es
summaryEl total del periodo pedido
previousSummaryEl mismo bloque para el periodo inmediatamente anterior, de la misma duración. Sirve para el «+12 % respecto al mes pasado» sin hacer dos llamadas
timelineUn resumen por día, para pintar una gráfica

El corte por canal viene calculado

byChannel te da el reparto entre online (la web de venta de la sala), boxOffice (mostrador) y api (tu integración).

Viene ya calculado a propósito. Podríamos dar solo los totales y dejar que cada cliente dedujera lo online restando los otros dos — y funcionaría, hasta el día que apareciera un canal nuevo y todas esas restas empezaran a dar de menos sin que nadie se enterara.

El informe es el mismo que el del panel

Usa el mismo motor que pinta el informe de ventas del panel. Si tu cuadro de mando y la pantalla de la sala dieran cifras distintas, la sala dejaría de creerse las dos.

timezone y currency

Vienen en la respuesta para que sepas cómo interpretar los datos. Los días de timeline están calculados en la zona horaria de la sala, no en UTC: una venta a las 00:30 de Madrid cuenta en ese día, no en el anterior.

Lo que no está aquí

Ventas por evento, por tarifa o por zona no están expuestas todavía. Si las necesitas, se pueden reconstruir recorriendo /orders con updatedSince y agregando por lines[].eventId, o escríbenos y nos ayudas a priorizarlo.