Air Scraper API Review: Real-Time Flights, Hotels & Cars

What Air Scraper does and who it is for

Air Scraper aggregates publicly available travel pricing data and serves it through a single REST interface. The core use cases are flight search (one-way, round-trip, multi-city, and flexible dates), hotel discovery with live OTA pricing, and car-hire search. If you are building a price-comparison site, a travel-planning tool, a fare-alert system, or simply need to embed flight prices in an existing product, this API covers the essential data layer.

The API is versioned: v1 endpoints exist mainly for backwards compatibility, v2 introduced a polling pattern for flight search, and v3 is the current recommended version with the richest endpoint set and cleaner semantics. Where the same capability exists across versions, prefer v3.

Endpoint walkthrough

Flights

The flights vertical is the deepest part of Air Scraper and follows a clear lookup-then-search pattern.

Location lookup is always the first step. Two endpoints handle this:

• GET /api/v3/flights/searchAirport — search by name or IATA code. Returns a list of matching airports, cities, and regions, each carrying a skyId (e.g. JFK) and an entityId (a numeric string). Both values are required by every downstream flight search call.
• GET /api/v3/flights/getNearByAirports — accepts GPS coordinates (lat, lng) and returns the nearest city plus surrounding airports. Useful when you have location access and want to auto-populate the departure field.

Core flight search is POST /api/v3/flights/searchFlights. You pass originSkyId, destinationSkyId, originEntityId, destinationEntityId, and a date in YYYY-MM-DD format. Optional parameters include returnDate, adults, cabinClass, childrens, infants, currency, market, sortBy, and countryCode. The endpoint returns itineraries with pricing, carrier details, and legs — but results may arrive in batches. When context.status is incomplete, you poll GET /api/v3/flights/searchIncomplete with the sessionId until status becomes complete. This polling pattern is the intended workflow for v2 and v3; the now-deprecated v1 searchFlights tried to return everything in a single (slow) call.

Specialty flight endpoints in v3 address several product features that simpler APIs leave out:

• POST /api/v3/flights/searchFlightsMultiStops — open-jaw / multi-city itineraries with at least two legs, each with its own origin, destination, and date.
• GET /api/v3/flights/getPriceCalendar — day-by-day prices from a given start date, suitable for rendering a calendar date-picker that highlights cheapest travel days.
• GET /api/v3/flights/getPriceCalendarFlexible — month-level cheapest prices for a route, useful for a "flexible dates" UI that lets users browse across months.
• POST /api/v3/flights/everywhereDestination — the "fly anywhere" feature: given an origin, returns all destination countries with pricing bucketed by cheapest and direct options.
• POST /api/v3/flights/countryDestination — drills into a specific country to list available cities with prices.
• POST /api/v3/flights/getFlightQuotes — indicative quotes for month-level or "anytime" departures, meant to be called before searchFlights when the user has not picked an exact date.

Hotels

The hotel flow mirrors the flight pattern. Start with GET /api/v3/hotels/searchLocation to resolve a city or landmark name into an entityId. Then call POST /api/v3/hotels/searchHotels to get a paginated list with prices, star ratings, and filter options; this response includes a poiId which is required for detail and pricing calls. GET /api/v3/hotels/getHotelDetails returns the full property profile — description, gallery, amenities, coordinates — while POST /api/v3/hotels/getHotelPrices returns live rates from OTA partners including Expedia, Hotels.com, and Booking.com, with deep-link booking URLs.

Additional hotel endpoints worth noting:

• POST /api/v3/hotels/searchHotelsByMap — search within a map bounding box, designed to be re-called as the user pans and zooms a map view.
• GET /api/v3/hotels/getCurrentLocation — resolves GPS coordinates to a hotel-search-compatible location without requiring a text query.
• GET /api/v3/hotels/getPriceBand — returns historical price-band analysis (low, median, high, outlier) for a hotel on given dates, letting you label current prices as a deal or expensive.
• POST /api/v3/hotels/getAtypicalDeals — city-level price-band stats, useful for surfacing unusually cheap listings across a destination.
• POST /api/v3/hotels/getReviews — paginated guest reviews with score breakdowns and filters for rating, language, guest type, and topic tags.

Cars

The rental-car vertical has a simpler two-step flow: GET /api/v3/cars/searchLocation to find entity_id values for pick-up and drop-off locations (airports, cities, train stations), then POST /api/v3/cars/searchCars to retrieve quoted vehicles with vendor info, pricing, inclusions, and booking URLs. Filters include vehicle type, transmission, and pick-up method; pick-up and drop-off times must be in 30-minute intervals.

Pricing breakdown

The BASIC tier is genuinely minimal — 20 requests per month is enough to prototype a single search flow but not to run any real user traffic. PRO at $9.99 gives you 10,600 requests, which at $0.094 per 1,000 requests is reasonable for a small production app or internal tool that does moderate searches. Note that multi-step flows (location lookup + search + polling) consume multiple requests per user action, so plan accordingly: a round-trip flight search that requires two or three poll cycles can cost 4–5 requests per user query.

ULTRA and MEGA are aimed at higher-traffic products. The overage rate drops from $0.0020 on PRO to $0.0010 on MEGA, so heavy-volume apps will find MEGA more cost-efficient once they consistently exceed 55,000 monthly requests.

Practical use cases

• Flight comparison widget — use searchAirport for autocomplete, searchFlights + searchIncomplete polling for results, and getPriceCalendar to let users pick the cheapest day.
• "Fly anywhere" inspiration page — everywhereDestination and countryDestination give you the data for a map or grid showing cheapest destinations from a given city.
• Hotel booking engine — the full v3 hotel stack covers search, map view, detail pages, live OTA pricing, reviews, and price-band context.
• Fare alerts — periodically call getPriceCalendarFlexible or getFlightQuotes for a route to detect price drops without burning requests on full search calls.
• Travel itinerary app — combine the flights and hotels verticals to surface coordinated flight and accommodation prices for the same destination and dates.

Limitations and things to check before integrating

Latency is the most significant practical concern. The reported average response time is 3,818 ms — nearly four seconds. This reflects the nature of live-scraping real pricing data in real time. You will need to design your UI around this: loading states, skeleton screens, and the explicit polling pattern for flight search are not optional. For fare-alert or batch use cases, the latency is less of a UX issue.

API versioning requires attention. V1 endpoints are deprecated or less capable, and the documentation sometimes labels the same functionality under different version paths. Before building, confirm you are using v3 endpoints, especially for flights where the v1 searchFlights is explicitly marked deprecated.

Request budgeting matters more here than with simpler APIs. Because the polling pattern means a single logical search can span several HTTP calls, map your expected user flows to request counts before choosing a plan.

Data source nature — the API reproduces publicly available data in real time. Terms of use and data freshness are governed by the upstream sources; production deployments that display or store this data should review those implications.

Getting started

Subscribe on RapidAPI and start with the BASIC tier to explore the endpoint responses. A minimal flight search needs three calls: searchAirport for origin, searchAirport for destination, then POST /api/v3/flights/searchFlights. Capture the sessionId from the response and poll searchIncomplete until context.status equals complete. For hotels, the same three-call pattern applies: searchLocation → searchHotels → getHotelPrices. Once you have mapped these flows and confirmed the response shapes match your data model, upgrade to PRO to handle real traffic.