Construir mi booking

API de Reservas

La misma puerta por la que entra nuestro propio panel.

No existe una versión reducida de Tiqory para integraciones. Un plugin de WordPress, una conexión de reventa o nuestro propio panel de administración llaman exactamente al mismo motor, a través de una clave acotada a lo que necesita, ni más ni menos.

  • 5 permisos products.read, checkout.create, leads.create, support.create y feedback.create, otorgados de forma independiente por clave
  • 10 a 10.000/min Cada clave define su propio límite de uso, aislado del resto de claves de la cuenta
  • Se muestra una vez El secreto completo aparece una sola vez; Tiqory solo guarda su hash y un prefijo de búsqueda

Cuatro piezas de control de acceso.

Cada una acota lo que puede hacer realmente una integración, sin acotar lo que puede hacer la plataforma.

01

Una clave con nombre por canal

"Web principal", "App móvil", "Agencia Roma": tantas claves como canales, cada una con un nombre que dice qué es, así que una fuga o un error se rastrea hasta una sola integración, nunca hasta toda la cuenta.

02

Permisos acotados, no una clave maestra

Una clave recibe exactamente los permisos que necesita: leer un producto, crear un checkout, enviar un lead, nunca acceso general a todo lo que puede hacer la API.

03

Pública donde ayuda, cerrada donde no

Cada organización decide, permiso por permiso, si un navegador puede llamarlo directamente o si debe pasar por un servidor con una clave. Leads, soporte y feedback siempre requieren una.

04

Rotación y revocación instantáneas

Una clave comprometida se rota, y cualquiera que siga usando el secreto anterior deja de funcionar en su siguiente solicitud, sin ningún token de expiración que esperar.

Cómo se resuelve

Así se autoriza una llamada, paso a paso

Cinco pasos, cada vez que una solicitud llega con una clave de API.

  1. 1

    La clave se autentica

    La clave en texto plano llega como prefijo.secreto. El prefijo busca la fila, y luego el secreto se compara contra su hash guardado con una verificación de tiempo constante, nunca una igualdad simple.

  2. 2

    Se comprueba el permiso

    La acción solicitada debe aparecer explícitamente en la lista de permisos otorgados a esa clave. Si falta, devuelve el mismo error genérico, exista la clave o no.

  3. 3

    Aplica el límite propio de la clave

    El tráfico de esa clave cuenta contra su propio límite configurado, aislado del de cualquier otra clave de la misma cuenta. El tráfico público sin clave cuenta por dirección IP.

  4. 4

    Cada consulta corre acotada, automáticamente

    Una vez autenticada, la llamada opera únicamente dentro de la organización de esa clave. No hay ningún camino de una clave hacia el catálogo de otro tenant, ni siquiera adivinando un id interno.

  5. 5

    La llamada queda registrada

    La última vez de uso y la IP que llamó se actualizan en cada solicitud exitosa, así que una clave olvidada o inactiva se vuelve visible mucho antes de que alguien piense en buscarla.

La API, tal cual

Una llamada, todo el payload de la tienda

Un producto buscado por su alias público devuelve sus opciones, tipos de entrada, fechas disponibles, precios resueltos y cupo restante, ya correctos para la moneda y el país de quien consulta.

GET /api/v1/products/city-food-tour
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
{
  "data": {
    "name": "City Food Tour",
    "alias": "city-food-tour",
    "currency": "EUR",
    "options": [
      {
        "code": "general",
        "next_slot": "2026-08-14T10:00:00+02:00",
        "remaining": 12,
        "price": {
          "amount": 42.5,
          "currency": "EUR"
        }
      }
    ]
  }
}
200 Producto resuelto

El detalle que casi nadie explica

Una clave equivocada y el producto de otro se ven idénticos

Un producto que pertenece a otra organización y un producto que simplemente no existe devuelven exactamente el mismo "no encontrado", nunca un error de permisos que confirme que el producto existe en algún otro lado. Una clave inválida o revocada tiene su propio error distinto, pero ninguna respuesta revela jamás si el recurso pedido pertenece a otro tenant.

Preguntas frecuentes

Rótala. La rotación emite de inmediato un nuevo prefijo y secreto e invalida el par anterior, así que cualquiera que siga usando el secreto filtrado empieza a fallar en su siguiente solicitud, sin ningún retraso de propagación que esperar.

No. Cada consulta autenticada con una clave corre acotada a la organización de esa clave. Un producto que pertenece a otra persona devuelve el mismo "no encontrado" que uno que directamente no existe.

No. products.read y checkout.create pueden llamarse directamente desde un navegador si la organización los deja públicos. leads.create, support.create y feedback.create siempre requieren una clave, porque existen justamente para llamarse desde un servidor que controla la organización.

Un límite por defecto razonable para cada permiso, contado por dirección IP: generoso para navegar, más estricto para crear un checkout o enviar un lead. Una clave sustituye ese valor por defecto con su propio límite configurado, de 10 a 10.000 solicitudes por minuto.

Una respuesta 429 con un encabezado Retry-After, además del límite y las solicitudes restantes, así una integración puede frenar automáticamente en lugar de adivinar cuándo reintentar.

Más reservas. Más canales. La misma calma.

Tiqory mantiene disponibilidad, precios, pagos y acceso trabajando juntos mientras tu operación crece. Cuéntanos hacia dónde vas; te mostramos cómo llegar sin volver a empezar.