Saltar al contenido
Tickeep
Índice de la API

Referencia de la API

Todos los endpoints de la API en una sola página, agrupados por recurso, con el permiso que exige cada uno.

Última actualización: 23 de agosto de 2026

El índice completo. Si ya conoces la API y solo quieres localizar la ruta que necesitas, es esta página; cada fila enlaza al apartado que la documenta en detalle.

URL base

https://app.tickeep.com/api/v1

Todas las rutas de abajo cuelgan de ahí, todas se autentican con una clave (Authorization: Bearer …) y todas devuelven JSON. Los parámetros entre llaves —{id}, {reference}, {code}— se sustituyen por su valor.

Todos los endpoints

Salas

El punto de entrada: de aquí salen los identificadores de sala.

1 endpoint
GET/venuesListar las salas que alcanza la clave

Eventos, fechas concretas y qué se puede vender ahora mismo.

5 endpoints
GET/eventsListar eventosGET/events/{id}Abrir un eventoGET/performancesListar fechas, en orden cronológicoGET/performances/{id}Abrir una fechaGET/performances/{id}/availabilityNo reserva nadaConsultar qué se puede vender ahora en esa fecha

Pedidos

La venta en dos tiempos: reservar el stock y después cobrar.

6 endpoints
POST/ordersExige Idempotency-KeyReservar entradas y abrir un pedidoGET/ordersListar pedidosGET/orders/{reference}Abrir un pedido por su referenciaPOST/orders/{reference}/confirmConfirmar que has cobrado y emitir las entradasPOST/orders/{reference}/payment-linkGenerar un enlace para que pague el compradorPOST/orders/{reference}/cancelAnular una reserva y liberar el stock

Entradas y control de acceso

Consultar las entradas emitidas y validarlas en puerta.

3 endpoints
GET/ticketsListar entradas emitidasGET/tickets/{code}Abrir una entrada por su códigoPOST/tickets/{code}/check-inResponde 200 siempreValidar una entrada en puerta

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

Permisos que exige cada uno

Una clave se emite con la lista de permisos que necesite y nada más. Estos son los siete que existen y qué abre cada uno:

PermisoEndpoints que habilita
catalog:read/venues, /events, /performances, /availability
orders:read/orders y /orders/{reference}
orders:writeCrear, confirmar, cancelar y generar enlace de pago
tickets:read/tickets y /tickets/{code}
tickets:validate/tickets/{code}/check-in
customers:read/attendees
reports:read/reports/sales

Dos de ellos arrastran lo que necesitan para ser útiles: orders:write incluye orders:read y catalog:read, y tickets:validate incluye tickets:read. No hace falta marcar los dos.

Ningún permiso concede administración

No verás en esta tabla ningún endpoint que cree eventos, cambie precios, invite a nadie o emita un reembolso: no existen. Una clave lee catálogo y mueve ventas; la administración de la cuenta vive en el panel. Ver la API de Tickeep.

Lo que se repite en todas las llamadas

Cuatro cosas valen para cualquier fila de la tabla de arriba, y por eso no se repiten endpoint a endpoint:

AutenticaciónAuthorization: Bearer tk_live_…, o X-Api-Key. Ver autenticación
ErroresSiempre { "error": "código_estable" }. Ver errores
PaginaciónPor cursor, hasta 100 por página. Ver paginación
Límite de uso120 peticiones por minuto y clave. Ver límites

Y dos convenciones que sorprenden si no se han leído antes: el dinero va en céntimos enteros ({ "amount": 1250, "currency": "EUR" }) y las fechas en ISO 8601 UTC. Están en convenciones.

Los tres endpoints que se comportan distinto

La mayoría hace lo que parece. Estos tres, no:

POST/orders

Exige la cabecera Idempotency-Key. Sin ella responde 400. Es el único endpoint donde un reintento a ciegas crearía un segundo pedido con su stock retenido. Ver idempotencia.

POST/tickets/{code}/check-in

Responde 200 siempre, con un campo result. Que una entrada esté repetida o anulada no es un error de la petición: es el veredicto del control. Ver entradas y control de acceso.

GET/performances/{id}/availability

No reserva nada. Es una foto que puede caducar entre la consulta y la compra; la verdad la fija POST /orders, que es atómico. Ver disponibilidad.

Eventos de webhook

Además de estos endpoints, Tickeep puede llamar a tu servidor cuando pasa algo. Son siete eventos:

EventoCuándo
order.paidEl pedido se ha cobrado y las entradas se están emitiendo
order.cancelledUna reserva pendiente se ha anulado y su stock está libre
order.refundedSe ha devuelto el importe de un pedido pagado
ticket.checkedInUna entrada se ha marcado como usada en puerta
ticket.voidedUna entrada ha dejado de ser válida
event.publishedUn evento ha pasado a estar visible
performance.cancelledSe ha cancelado una fecha concreta

El objeto que viaja en data es exactamente el mismo que devuelve la API. Ver webhooks.

Qué no hay

Para que no lo busques:

  • Nada de escritura en el catálogo. No hay POST /events ni forma de editar tarifas, precios o aforos.
  • Nada de reembolsos. Mueven dinero real y se hacen desde el panel.
  • Nada de administración. Ni miembros, ni salas, ni facturación, ni suscripción.
  • PATCH, PUT y DELETE. La API no edita ni borra recursos: lee, y hace transiciones de estado a través de acciones con nombre (/confirm, /cancel, /check-in).