Da de alta una ruta y vigila lo que cuesta volar a tu ciudad

Al terminar tendrás una ruta en tu cuenta, una tarifa en vivo en pantalla y la serie almacenada que convierte esa tarifa en una señal de demanda para las noches que alimenta.

Qué necesitas: una cuenta con la Account API activa y los dos aeropuertos que te importan.

Qué cuesta: crear la ruta es gratis. La llamada en vivo consume créditos por petición; el feed almacenado es la lectura barata, y los créditos se van en las importaciones que lo llenan.

Por qué dar de alta una ruta si la llamada en vivo no necesita nada

Esta es la pregunta que hay que responder primero, porque el endpoint de tiempo real acepta de verdad dos códigos IATA y una fecha y te devuelve tarifas — sin entidad, sin montaje, sin configurar nada.

La entidad está para otra cosa. Una tarifa suelta no te dice casi nada. Madrid–Barcelona a 180 € es caro o barato según lo que costara ayer, la semana pasada y la misma semana del año pasado. Lo que mueve una decisión de revenue es la serie: la misma ruta, el mismo punto de venta, revalorada día tras día. Da de alta la ruta y Veetal guarda cada extracción; entonces la lectura del feed es barata y repetible, y cada llamada en vivo que ibas a poner en un bucle es un crédito que no gastas.

Dicho de otro modo: Real Time responde "cuánto cuesta ahora". Feed responde "qué le está pasando a esta ruta". Solo una de las dos es un indicador adelantado.

1. Los aeropuertos, resueltos gratis

Los aeropuertos son datos de catálogo, así que resolverlos no cuesta nada — la búsqueda de catálogo (type=airports) es gratuita, 0 créditos, y el autocompletado del asistente los resuelve por ti mientras escribes.

Solo Londres ofrece siete aeropuertos con sus códigos IATA. Importa más de lo que parece: LGW y LHR no son el mismo mercado emisor, y una ruta montada sobre el que no es responde correctamente sobre una ciudad desde la que tus huéspedes no vuelan.

Los aeropuertos se resuelven en local, lo que convierte a los vuelos en la más autosuficiente de las cuatro entidades — funciona incluso cuando las OTAs tienen un mal día.

2. Crea la ruta

En Flights, Add flights. Escribe una ciudad y el autocompletado te da sus aeropuertos con su código IATA. Después, tipo de viaje, fechas y pasajeros.

• Round trip pide un rango de fechas.
• One way acepta una fecha suelta.

3. El punto de venta no es la ruta

Hay dos campos obligatorios y fáciles de pasar por alto: LANGUAGE y COUNTRY.

No son el origen del vuelo. Son el punto de venta — el mercado cuyos precios quieres ver. La misma plaza en el mismo avión se tarifica distinto para un navegador en España que para uno en Estados Unidos, y cuál de los dos estás mirando es una decisión, no un trámite. Si sigues la demanda alemana hacia Barcelona, el punto de venta es Alemania aunque la ruta sea la misma.

Deja uno vacío y el campo se pone rojo con This field is required, y Add flight se queda deshabilitado. Ese botón deshabilitado es el "el formulario está roto" más repetido de esta pantalla.

Ese mismo campo decide la moneda que te devuelve el endpoint en vivo: location=ES responde en euros, US en dólares, MX en pesos mexicanos.

4. Una llamada en vivo, sin montar nada

GET /v2/real-time/flight/rate/airport/{origin}/{destination}/{departure_date}

Añade return_date para ida y vuelta, adults, children, infants para el pasaje, location y language para el punto de venta, y order_by=price o recommended.

Responde en unos segundos con los vuelos a la venta: aerolínea, horarios, escalas, equipaje, CO2 y los segmentos de cada itinerario. Al ser Real Time es cacheable — la ventana de caché se configura por API en el dashboard, de 0 a 24 horas, y no_cache=true fuerza una respuesta fresca que no se guarda como parte de los parámetros.

Esta llamada es la herramienta correcta para una pregunta puntual: cuánto cuesta volar para el fin de semana de ese congreso.

5. La misma ruta, todos los días

Para tener serie, activa la ruta en la Feed API de tarifas de vuelo y lanza la primera importación a mano — lee la estimación de créditos antes de pulsar y después ponla en un schedule para que la serie siga llenándose.

GET /v2/feed/flight/{flight_id}/rates

El flight_id es el id de la entidad que acabas de crear, que sale de GET /v2/account/flight. La forma depende del tipo de viaje: un one way devuelve flights[], y una ida y vuelta devuelve outbound_flights[] y return_flights[], cada vuelo con su aerolínea, horarios, escalas, equipaje y CO2.

Pasa import_id o import_date para leer una extracción concreta. Sin ellos te llevas la última — que es lo que quieres en un panel, y no lo que quieres cuando estás construyendo la curva.

De qué es indicador adelantado, y de qué no

No es un contador de reservas. Nadie te vende cuánta gente ha comprado plaza.

Lo que sí es: el precio y la forma de llegar. Tarifas subiendo para una semana concreta, tarifas baratas que desaparecen, vuelos directos que se agotan hasta que solo quedan itinerarios con dos escalas — eso es el mercado tensándose para esas fechas, y pasa mientras tu propio ritmo todavía parece normal. Crúzalo con el calendario de eventos de la misma ciudad y tienes las dos mitades de la misma historia: los eventos te dicen por qué viene la demanda, la ruta te dice si ya se está comprando.

Qué viene después

Da de alta las dos o tres rutas que alimentan tu ciudad de verdad — tus mercados emisores principales, no todos los aeropuertos del mundo — y empareja la serie con el feed de eventos. La receta Flight-Demand Forecast hace exactamente eso con los datos que produce este montaje.