---
title: "How to Build an AI Reservation Agent Using a Unified Commerce API"
img: https://s3.us-east-2.amazonaws.com/unified-article-images/how_to_build_an_ai_reservation_agent_using_a_unified_commerce_api-icon.png
date: 2026-03-24T23:54:00.000Z
tag: Product
description: "An AI booking agent translates user intent into API calls that search locations, retrieve availability, and create reservations. Using the Unified Commerce..."
url: "https://unified.to/blog/how_to_build_an_ai_reservation_agent_using_a_unified_commerce_api"
---

# 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](https://unified.to/commerce), 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.


| Object       | Role in agent                 |
| ------------ | ----------------------------- |
| Location     | where the booking happens     |
| Availability | available time slots          |
| Reservation  | confirmed booking             |
| Review       | optional ranking or filtering |
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


```typescript
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


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


The agent can:

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

### Step 3: Retrieve availability


```typescript
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:


```typescript
const selectedSlot = availabilities.data[0];
```


### Step 5: Create reservation


```typescript
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:


```typescript
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


| Integration | Behavior                   |
| ----------- | -------------------------- |
| SevenRooms  | full reservation lifecycle |
| OpenTable   | create-only                |
| Yelp        | create-only                |
| resOS       | create-only                |
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/replacing_polling_with_unified_webhooks_and_virtual_streams)](/blog/unlock_real_time_data_with_virtual_webhooks) (polling-based)
- or poll reservation endpoints directly

### Track status changes


| Status    | Meaning               |
| --------- | --------------------- |
| PENDING   | awaiting confirmation |
| CONFIRMED | accepted              |
| CANCELLED | cancelled             |
| NO_SHOW   | missed                |
| COMPLETED | finished              |
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](/commerce):

- 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](https://app.unified.to/login)


→ [Book a demo](https://calendly.com/d/cph9-g8n-jzg/connect-with-unified)