How to Build an AI Reservation Agent Using a Unified Commerce API

March 24, 2026

An AI booking agent translates user intent into API calls that search locations, retrieve availability, and create reservations. Using the Unified Commerce API, developers can implement this flow across OpenTable, Yelp, SevenRooms, and resOS with a consistent set of objects and endpoints.

What an AI booking agent actually does

An AI booking agent is not a generic chatbot. It is a system that:

1. interprets user intent
2. calls structured APIs
3. makes decisions based on real data
4. executes a booking

For example:

'Book dinner for 2 near me at 7pm'

The agent must:

• find relevant locations
• retrieve available time slots
• select a valid option
• create a reservation

This requires structured API access, not scraping or static data.

Why booking is a strong AI use case

Booking is one of the most practical applications for AI agents because:

• inputs are structured (time, party size, location)
• outputs are constrained (available slots)
• success is binary (reservation created or not)

Unlike open-ended workflows, booking has:

• clear constraints
• deterministic APIs
• a defined execution step

Reservation-based commerce model

AI booking relies on a specific subset of commerce integrations.

Important constraint:

• Availability is read-only
• Reservation is the write path

Agent architecture

A production-ready AI booking agent typically includes:

1. Intent layer (LLM)

Parses:

• time ('7pm')
• party size ('2 people')
• location ('near me')

2. Tool layer (Unified Commerce API)

Provides structured operations:

• list locations
• retrieve availability
• create reservation

3. Decision layer

Selects:

• best location
• best time slot

4. Execution layer

Creates the reservation and returns confirmation.

Step-by-step implementation

Step 1: Initialize the SDK

import { UnifiedTo } from "@unified-api/typescript-sdk";

const sdk = new UnifiedTo({
  security: { jwt: process.env.UNIFIED_API_KEY! },
});

Each user must have a connectionId for their authorized integration.

Step 2: Search locations

const locations = await sdk.commerce.listCommerceLocations({
  connectionId,
});

The agent can:

• filter by name or proximity (externally)
• rank based on relevance

Step 3: Retrieve availability

const availabilities = await sdk.commerce.listCommerceAvailabilities(
  connectionId,
  {
    locationId: selectedLocationId,
    startGte: "2026-05-01T18:00:00Z",
    endLt: "2026-05-01T22:00:00Z",
    size: 2,
    limit: 20,
  }
);

Key points:

• availability is read-only
• filtering is critical for agent performance
• results return valid bookable time slots

Step 4: Select a time slot

The agent chooses based on:

• closest match to requested time
• availability density
• optional business logic

Example:

const selectedSlot = availabilities.data[0];

Step 5: Create reservation

const reservation = await sdk.commerce.createCommerceReservation({
  connectionId,
  commerceReservation: {
    locationId: selectedSlot.location_id,
    startAt: selectedSlot.start_at,
    endAt: selectedSlot.end_at,
    size: 2,
    guestName: "Jane Doe",
    guestEmail: "jane@example.com",
  },
});

Important:

• this is the execution step
• all prior steps are preparation

Step 6: Confirm result

The response includes:

• reservation ID
• status
• timestamps

Example:

console.log(reservation.id, reservation.status);

Handling real-world constraints

AI agents must handle incomplete or inconsistent support across integrations.

Availability constraints

• always read-only
• may differ in structure across integrations

Reservation constraints

Implication:

the agent should prioritize successful creation, not full lifecycle control

Field variability

Not all integrations support:

• staff assignment
• item-level booking
• full guest data

Design the agent to:

• use minimal required fields
• extend when supported

Designing agent logic

1. Constrain the search space

Always filter:

• time range (startGte, endLt)
• party size (size)
• location (locationId)

2. Avoid over-optimization

Do not attempt:

• complex ranking models
• cross-provider aggregation

Start with:

• first valid slot
• or closest match

3. Handle failure paths

If no availability:

• expand time window
• suggest alternatives

If reservation fails:

• retry with another slot

Monitoring booking outcomes

Most integrations do not provide native webhook support.

Instead:

• use [virtual webhooks](/blog/unlock_real_time_data_with_virtual_webhooks) (polling-based)
• or poll reservation endpoints directly

Track status changes

Key insight:

reservation status is the source of truth for booking state

Why this works with a unified API

Without a unified model:

• each integration requires separate logic
• availability filters differ
• reservation payloads vary

With the Unified Commerce API:

• same objects across integrations
• same API structure
• same implementation pattern

Requests are executed directly against each integration, so availability and reservation responses reflect the current state of the underlying platform.

Key takeaways

• AI booking agents require structured APIs, not scraped data
• availability is the discovery layer, reservation is the execution layer
• the agent loop is: intent → availability → decision → reservation
• integration support varies beyond reservation creation
• reservation status defines lifecycle state
• a unified API allows one implementation across multiple booking integrations

→ Start your 30-day free trial

→ Book a demo