canonical: https://jentic.com/apis/impala.travel

# Impala APIs

Impala provides hotel content, rates, and booking APIs that let travel apps add room search and reservations without integrating with each property directly. The portfolio spans two versions of the same booking surface: a v1 API covering hotel listings, rate plans, availability calendars, the full reservation lifecycle, and a JWT payment authorisation flow, and a streamlined v2 API covering hotel search, room types, rates, and booking creation, retrieval, and cancellation. Both expose a uniform schema across many properties so an integration does not have to negotiate channel manager connections per hotel.

## For AI agents

An agent can search hotels by destination and dates, pull rate plans or room types and availability, and create, retrieve, modify, or cancel bookings across Impala's v1 and v2 APIs. This suits travel marketplaces, AI concierges, and booking automation that need hotel inventory and reservation control from one provider.

## Scope

Use for: Hotel search, rate and availability retrieval, and the create, retrieve, modify, and cancel booking lifecycle across Impala's v1 and v2 APIs.

Not supported:
- flight bookings
- ground transport
- activities and tours
- channel manager sync
- loyalty programs

## APIs

| API | Category | Endpoints | Description |
| --- | --- | --- | --- |
| Impala Hotel Booking API | e-commerce | 10 | Search hotels, retrieve rate plans, and create or cancel hotel bookings. |
| Impala Hotel Bookings API | e-commerce | 8 | Search hotels, fetch room types and rates, and manage hotel bookings. |

## Which API to use

| Need | API | Why |
| --- | --- | --- |
| New hotel search and booking integration | impala-hotel-bookings | The v2 surface is smaller and more uniform, with hotel search, room types, rates, and a simple x-api-key booking flow, making it the preferred starting point for new builds. |
| Rate calendar or built-in payment authorisation | impala-hotel-booking-api | The v1 API exposes explicit rate plan calendars and a JWT payment intent flow for card capture that the v2 surface does not include. |
| Cancel an existing reservation | impala-hotel-bookings | v2 cancels through POST /bookings/{bookingId}/cancel, while v1 cancels through DELETE /bookings/{bookingId}; pick the version your booking was created on. |

## Cross-API use cases

### Version-aware hotel booking

Route new bookings to the v2 surface for hotel search, room types, and rates while keeping v1 available for rate calendars and payment authorisation, so an agent can operate a hotel booking flow that works whichever version a reservation lives on.

Example prompt: Search hotels in Lisbon for two nights on the v2 API, create the booking, and if the property is only available on the v1 rate plan calendar, fall back to the v1 API to price and book it.

### Reservation cancellation across versions

Look up a booking and cancel it regardless of which Impala version created it, using DELETE /bookings/{bookingId} on v1 or POST /bookings/{bookingId}/cancel on v2, returning the cancellation reference to the user.

Example prompt: Given a booking id, detect whether it was created on v1 or v2 and cancel it on the correct API, then return the cancellation confirmation to the support ticket.

### AI travel concierge over Impala inventory

Power a concierge that compares hotels and confirms reservations, using the v2 search, room types, and rates endpoints for new stays and the v1 payment authorisation flow when a booking needs card capture handled through Impala.

Example prompt: Take a user's destination, dates, and budget, list the cheapest available room types from v2, and confirm a booking on approval, using the v1 payment flow where card authorisation is required.

## Why Jentic

- **Setup:** Wiring Impala by hand means managing the x-api-key header, the v1 payment bearer JWT, the choice between sandbox and production hosts, and two versions of the booking lifecycle yourself. Through Jentic you install Jentic One once, add the Impala APIs from the Jentic directory, store the credentials once, and your agent calls them.
- **Permission scoping:** Impala puts hotel id and booking id in the URL path across both versions, so your own rules can pin an agent to a specific booking. You choose which operations the agent may call, so destructive ones like cancelling a booking are not available unless you add them.
- **Credential handling:** Your Impala x-api-key and the v1 payment JWT are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** An agent searches the Jentic directory by intent such as 'search hotels' or 'create a hotel booking', and Jentic returns the matching Impala operation with its input schema so the agent calls the right endpoint on the right version without browsing the reference docs.

## Related vendors

- **Booking.com** — Major OTA with much broader hotel inventory and an affiliate booking flow, an alternative when reach matters more than direct commission and white-label control.
- **Cloudbeds** — Property management system on the hotel side, useful for hoteliers receiving and managing Impala-originated reservations in their PMS.
- **Amadeus** — Airport and city search plus wider travel content that can resolve destinations and enrich input before searching Impala hotels.

## FAQ

### What can I build with Impala's APIs together?

You can add end-to-end hotel booking to a travel app: search properties, price rooms with rate plans or room types, and create, retrieve, modify, and cancel reservations. The v2 API covers new builds while the v1 API adds rate calendars and a payment authorisation flow, so together they support marketplaces, AI concierges, and cancellation automation.

### What is the difference between the v1 and v2 Impala APIs?

The v1 Impala Hotel Booking API has ten endpoints and includes explicit rate plan calendars plus a JWT payment authorisation flow. The v2 Impala Hotel Bookings API has eight endpoints with a smaller, more uniform surface for hotel search, room types, rates, and bookings. Prefer v2 for new builds and keep v1 for existing integrations that depend on its rate calendar model.

### Which version should I choose for a new integration?

Start with the v2 Impala Hotel Bookings API. It has a smaller, more uniform set of endpoints and uses a simple x-api-key flow. Use v1 only when you need its explicit rate calendar endpoints or its built-in payment authorisation flow, or when maintaining a client already built against v1.

### Does one Impala credential work across both APIs?

Yes. Both APIs authenticate with an x-api-key header from your Impala account, so a single key covers hotel and booking calls across v1 and v2. The v1 payment authorisation endpoint additionally requires a bearer JWT for card capture.

### Can an agent cancel a booking on either API?

Yes, though the operation differs by version. v1 cancels with DELETE /bookings/{bookingId} and v2 cancels with POST /bookings/{bookingId}/cancel. In both cases refund treatment follows the cancellation policy attached to the rate at the time of booking.

### Do the APIs offer a sandbox for testing?

The v1 API provides a sandbox host that returns realistic test data alongside a separate production host, so booking flows can be validated before going live. Point your integration at the sandbox first, then switch to production once the flow is confirmed.

### What kinds of travel products do these APIs cover?

They cover hotels only: content, rates and availability, room types or rate plans, and the reservation lifecycle. They do not handle flights, ground transport, or activities, so pair Impala with other providers if your app needs those product types.