Impala APIs for AI Agents
E CommerceOrder ManagementMixed ProvenanceapiKey, bearerAPI keyAgent Ready
For Agents
APIs2 in catalogue
Endpoints18 indexed
AuthapiKey, bearer / API key
ProvenanceMixed provenance
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.
Impala exposes hotel inventory and the full booking lifecycle through a single normalised schema, so a travel app can list properties, price rooms, and confirm reservations without wiring up individual hotel channel managers. Its two API versions let teams pick the smaller v2 surface for new builds while keeping the v1 rate calendar and payment authorisation flow available for existing integrations.
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
Credentials: Both APIs authenticate with an x-api-key header issued from your Impala account, and the v1 API additionally requires a bearer JWT for its payment authorisation endpoint, so one Impala key covers hotel and booking calls across the portfolio.
Across 2 Impala APIs: 1 vendor-official, 1 third-party, all indexed by Jentic and kept validated and agent-ready.
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.
Impala API Catalog
2 APIs across 1 product group.
Which Impala API should I use?
| I want to... | Use | Why |
|---|---|---|
| New hotel search and booking integration | Impala Hotel Bookings API | 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 API | v2 cancels through POST /bookings/{bookingId}/cancel, while v1 cancels through DELETE /bookings/{bookingId}; pick the version your booking was created on. |
Install Jentic One Beta
Connect the Impala APIs to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Impala APIs, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fimpala.travel" | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fimpala.travel" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Once connected, ask your agent something like: “search hotels and manage bookings”.
What AI Agents Can Do with Impala
Each workflow spans multiple Impala APIs. Jentic routes each operation to the right API automatically.
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.
APIs used
Impala Hotel Bookings API + Impala Hotel Booking API
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.
APIs used
Impala Hotel Booking API + Impala Hotel Bookings API
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.
APIs used
Impala Hotel Bookings API + Impala Hotel Booking API
Why Jentic?
What agents get from Jentic-routed access to this vendor.
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 isolation
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.
Intent-based discovery
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.
FAQs
Specific to using Impala APIs through Jentic.
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.
If you need a different E Commerce vendor
All 3 are in the Jentic catalogue with the same one-credential, intent-search pattern.
BOOK A DEMO
Start Connecting APIs to Your AI Agents
Browse thousands of APIs and connect them all to your agent with Jentic One. One layer, one credential — every API your agent needs.