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.
API de Reservas
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.
Cada una acota lo que puede hacer realmente una integración, sin acotar lo que puede hacer la plataforma.
"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.
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.
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.
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
Cinco pasos, cada vez que una solicitud llega con una clave de API.
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.
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.
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.
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.
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
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.
{
"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"
}
}
]
}
}El detalle que casi nadie explica
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.
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.
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.