Servicio · Integración
API para agencias
REST sobre JSON, autenticación OAuth 2.0, límites de peticiones declarados y entorno de pruebas permanente.
Diseñada para integrarse, no para lucirse
La API expone los mismos recursos que utiliza nuestra propia interfaz: búsqueda, tarificación, reserva, emisión, reemisión y consulta de estado. Es REST sobre JSON, con verbos previsibles, códigos de estado HTTP estándar y errores descritos en un cuerpo uniforme con código, mensaje legible y campo afectado.
No hay SDK obligatorio ni formatos propietarios. Quien ya integra un GDS reconocerá la estructura al primer vistazo; quien viene de cero puede tener una búsqueda funcionando en una tarde a partir de los ejemplos de la documentación.
Autenticación y entornos
La autenticación es OAuth 2.0 con el flujo de credenciales de cliente. Su sistema intercambia un identificador y un secreto por un token portador de vida corta, que se renueva de forma transparente. Cada agencia dispone de credenciales separadas para el entorno de pruebas y para producción, y de la posibilidad de emitir credenciales adicionales por aplicación para poder revocarlas de forma independiente.
El entorno de pruebas es permanente, no una demo temporal. Contiene datos representativos, permite emitir contra proveedores simulados y, sobre todo, permite provocar a voluntad los escenarios que en producción no se pueden ensayar: una cancelación, un cambio de horario, una denegación de emisión por plazo vencido o una caída de una de las fuentes.
Límites de peticiones y latencia
Publicamos el límite de peticiones asociado a cada contrato y la relación look-to-book esperada. No son cifras ocultas: figuran en el panel de la agencia y en las cabeceras de cada respuesta, con el número de peticiones restantes y el momento en que se reinicia la ventana.
Cuando se supera el límite, la respuesta es un 429 Too Many Requests con la cabecera Retry-After. Nunca devolvemos un error genérico ni cortamos la conexión sin explicación. Recomendamos implementar reintento con espera exponencial y algo de aleatoriedad, para que un pico de su lado no se convierta en una ráfaga sincronizada.
En cuanto a tiempos, la búsqueda con caché caliente responde en el entorno de los cientos de milisegundos, mientras que una consulta en vivo contra varias fuentes depende del proveedor más lento de la combinación. La respuesta incluye siempre el tiempo consumido y el desglose por fuente, de modo que pueda decidir si le compensa esperar a la fuente lenta o mostrar resultados parciales.
Idempotencia en las operaciones que cuestan dinero
Las peticiones de reserva y emisión aceptan una cabecera de clave idempotente. Si su sistema reintenta tras un tiempo de espera agotado, recibirá el resultado de la operación original en lugar de emitir dos veces el mismo billete.
Webhooks de interrupción
La parte más útil de la integración no es la búsqueda: es enterarse de que algo ha cambiado sin tener que preguntar. Registrando una URL de destino recibirá eventos firmados con HMAC-SHA256 cuando cambie el estado de un vuelo de sus expedientes: cancelación, gran retraso, cambio de horario, cambio de terminal o de puerta, y desincronización de equipaje.
Cada envío incluye la firma en una cabecera, una marca temporal para evitar reenvíos maliciosos y un identificador de evento estable que permite descartar duplicados. Si su extremo no responde, reintentamos con espera creciente durante veinticuatro horas y dejamos el evento accesible por API para que pueda recuperarlo después.
Versionado y compatibilidad
La versión va en la ruta (/v2/). Dentro de una versión mayor solo añadimos campos: nunca eliminamos ni cambiamos el significado de uno existente, de modo que su integración no se rompe porque nosotros publiquemos algo nuevo. Cuando una versión mayor queda obsoleta, se anuncia con doce meses de antelación y se mantiene operativa durante ese plazo.
Los cambios se publican en un registro con fecha, y las agencias integradas reciben aviso por el contacto técnico designado en el contrato.
Seguridad y datos
Todo el tráfico va cifrado con TLS. No se aceptan credenciales por parámetros de consulta. Los datos de tarjeta no pasan por nuestra API: el cobro se delega en una pasarela certificada en PCI DSS y en el expediente solo queda una referencia tokenizada. El tratamiento de los datos de pasajero se rige por el contrato de encargo firmado con su agencia, en los términos descritos en la política de privacidad.
La documentación completa, con ejemplos de petición y respuesta para cada recurso, se entrega al abrir el entorno de pruebas.
Le abrimos el entorno de pruebas
Sin compromiso y sin caducidad: su equipo técnico puede evaluarlo con calma antes de decidir.