Get real-time hotel prices from Booking, Expedia and Google Hotels through one API: live multi-OTA rates, no scraping. 1,000 free credits to start.
A real-time hotel prices API is an interface that returns the current, live nightly rate for a hotel across multiple online travel agencies (OTAs) in a single request. Veetal Connect API does exactly that: with one call it fetches a property's live price from Booking.com, Expedia, Google Hotels, Hotels.com and Airbnb, normalized into clean JSON with timestamps — no scrapers to build or maintain. This guide explains how live multi-OTA pricing works, what a request looks like, how caching and credits keep cost predictable, and where it fits in a revenue or comparison product.
Why hotel prices are hard to get in real time
A hotel room is not sold at one price in one place. The same property is distributed across dozens of channels, each showing a different number depending on who is looking and how. That fragmentation is exactly why a real-time hotel prices API exists.
- A single property is listed on many OTAs at once, each with its own rate, board, cancellation policy and member discount.
- Prices change constantly — by length of stay, occupancy, device (mobile vs desktop) and loyalty tier (Booking Genius, mobile-only deals).
- OTAs expose prices through public search pages, not clean data feeds, so teams often resort to scraping — which breaks on every layout change and gets throttled by anti-bot measures.
- Metasearch sources such as Google Hotel Ads aggregate many OTAs at once, but reconciling them with your own direct rate still requires a normalized structure.
The result: getting one trustworthy "what does this room cost right now, everywhere" answer is surprisingly hard. A real-time hotel prices API collapses that into a single request.
How a multi-OTA real-time price API works
Veetal exposes live pricing through its Real Time API family (realtime_*), which fetches on demand from the OTAs and returns normalized JSON. The workhorses for live prices are:
- Hotel parity across all OTAs — the parity endpoint returns the live price for a stay across every OTA listed on Google Hotel Ads in one call: one rate per OTA, each with a booking link and cancellation details. Typical latency is 4–14 seconds. This is the fastest way to answer "what does this hotel cost on every channel right now?".
- Booking.com live rates — the Booking rates endpoint returns room-level rates on Booking.com: nightly and total price, capacity, meal plan, cancellation policy, and Genius/mobile offers.
- Generic OTA rates — a per-OTA live rates endpoint when you need a single channel in isolation.
- Airbnb listing price — an Airbnb listing endpoint returns the live total price and breakdown for one listing, so short-term rentals sit in the same comparison as hotels.
Supported live sources for pricing: Booking.com, Expedia, Google Hotels, Hotels.com and Airbnb. (Structured multi-OTA reviews and reputation have separate endpoints; this article is about price.)
What each live price includes
Because the response is normalized, you get structured fields instead of raw HTML — ready to render or store directly:
- Price per night and total for the stay, with currency.
- Room type and capacity (adults/children).
- Board / meal plan (room only, breakfast, half board, full board, all inclusive).
- Cancellation policy (free-cancellation flags and deadlines).
- Channel-specific offers: Booking Genius, mobile-only rates, member discounts.
- A deep link to the booking page on that OTA.
Two layers: Real Time vs Feed
Live lookups are one half of the platform. The other is a stored, pre-processed Feed layer for history and managed competitor sets. Knowing which to call keeps latency and cost under control.
Feed API (feed_*) | Real Time API (realtime_*) | |
|---|---|---|
| Data | Pre-processed, stored reports from scheduled imports | Live, on-demand fetch from the OTA |
| Best for | Daily rate history for your hotels + competitor set | "Price right now" for any hotel/OTA |
| Cost | Cheap reads | Consumes credits per call |
| Latency | Instant (already stored) | Seconds (live fetch) |
| Example | Daily compset rates report | Live multi-OTA parity lookup |
Rule of thumb: use Real Time when a user is waiting for a fresh number (a comparison widget, a shopping session); use Feed when you need trends, history or a managed competitor set without paying per call. The two share the same hotel rates data model.
What a request looks like
A live multi-OTA price lookup is a single GET against the parity endpoint:
GET /v2/realtime/hotel/parity?reference_type=accommodation&reference=grand-hotel-central&checkin=2026-09-10&checkout=2026-09-12&adults=2
The response is one entry per OTA, each with the live price, currency, a deep link and cancellation info — already normalized, so you never parse HTML. You can reference a hotel three ways: your own configured property by slug, a Google Hotel Ads entity code, or (for Booking-specific calls) the Booking entity. If the property isn't configured yet, Veetal auto-creates it on first use.
To force fresh data instead of a cached response, add the global no_cache=true query parameter.
Caching and credits: keeping cost predictable
Real Time calls consume credits, so Veetal gives you a configurable cache (0–24 h per API, set in the dashboard). When caching is on and a valid response exists inside the window, the API returns the cached value with no extra fetch — ideal for a comparison page where many users view the same hotel and dates within minutes. When you need guaranteed-fresh pricing (a checkout confirmation), no_cache=true bypasses the cache.
A practical cost pattern:
- Serve most traffic from a short cache (e.g. 1–3 h) to absorb repeat views.
- Bypass the cache only at high-intent moments (final price confirmation).
- For dashboards and trend charts, read from the Feed layer instead of paying per live call.
New accounts get 1,000 free credits to prototype this before committing.
Use cases
- Price comparison tools / metasearch — show a live "from €X on Booking, €Y on Expedia" table for each property using the parity endpoint, and mix in Airbnb via the listing endpoint.
- Revenue management — monitor how your rate ranks against the competitor set and across channels; combine live checks with the stored daily hotel rates feed. The competitor rate grid recipe builds exactly that comparison — your hotel against its comp set — in a single call.
- Rate parity / disparity monitoring — detect when an OTA undercuts your direct or contracted price. See the hotel disparities dataset and our guide to hotel rate parity.
- Travel agencies & booking engines — surface the cheapest live channel for a given stay at search time.
Example: a comparison widget
A metasearch startup wants a "best price across channels" module. On each hotel page it calls the parity endpoint with the user's dates, caches the result for two hours, and renders one row per OTA with a deep link. Airbnb inventory in the same city is added through the Airbnb listing endpoint. No scraper fleet, no layout-break incidents — one normalized response per property, and cost stays flat because repeat views hit the cache.
If you would rather see the response before writing any of this, the live rate-shopper recipe fetches one live Booking.com rate on demand, and running your first real-time call from the playground walks through reading it and copying the same request into your own code.
Why not just scrape the prices?
Many teams start by scraping OTA search pages. In practice that is brittle: the price sits inside JavaScript-rendered HTML that changes without notice, anti-bot measures throttle or block requests, and you get raw markup rather than structured fields such as meal plan or cancellation policy. An API returns stable, normalized data that survives redesigns and scales predictably. (For a deeper comparison, see Hotel API vs Web Scraping.) The market rewards getting this right: Statista put global online travel revenue at over US$600 billion in 2024, and reliable, structured pricing is the foundation for competing in it. If you are new to the category, start with What Is a Hotel Data API?.
Frequently asked questions
What is a real-time hotel prices API?
It is an API that returns the current live nightly rate for a hotel, usually across multiple OTAs, in one request. Veetal Connect API returns one normalized rate per OTA (Booking, Expedia, Google Hotels, Hotels.com, Airbnb) with a booking link and cancellation details.
Which OTAs are supported for live pricing?
Booking.com, Expedia, Google Hotels, Hotels.com and Airbnb. The parity endpoint returns every OTA listed on Google Hotel Ads for the stay in a single call.
How fast is a live price request?
A parity lookup typically returns in 4–14 seconds because it fetches live from the channels. Cached responses (within the configured 0–24 h window) return instantly.
How do I control cost?
Live calls consume credits. Use the configurable per-API cache to serve repeat views for free, read history from the Feed layer instead of live calls, and add no_cache=true only when you genuinely need fresh data. Accounts start with 1,000 free credits.
Can I get historical prices too?
Yes. The Feed API stores daily rates for your hotels and competitor set, so you get history and trends without paying per live call.
Do I need to configure the hotel first?
No. You can reference a configured property by slug, or pass a Google Hotel Ads or Booking entity; Veetal auto-creates the property if it does not exist yet.
Get started
Ready to pull live multi-OTA prices? Start with 1,000 free credits, no card required → connect-api.veetal.app/funnel. Explore the hotel rates dataset or see pricing.
