How to Build Booking Into Your Product Across OpenTable, Yelp, SevenRooms, and resOS

March 24, 2026

Booking integrations let SaaS products search locations, retrieve available time slots, and create reservations directly inside their product. Using the Unified Commerce API, developers can implement this flow across reservation-based commerce integrations with a consistent set of objects and API calls.

Why booking integrations are difficult

Adding booking into a product sounds simple:

• show available time slots
• let the user pick one
• confirm the reservation

In practice, each integration behaves differently:

• availability is structured differently
• time filters vary across APIs
• reservation payloads are inconsistent
• post-booking operations are not always supported

Most teams end up building separate logic per integration just to support a single product feature.

Reservation-based vs catalog-based commerce

Commerce integrations are not one uniform category.

There are two distinct patterns:

This article focuses on reservation-based commerce, where the product experience is driven by time slots and bookings instead of inventory and products.

The booking data model

A booking flow is built around four core objects:

Key constraint:

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

How the booking flow works

Step 1: List locations

Retrieve available venues:

GET /commerce/{connection_id}/location

TypeScript:

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

This returns the list of bookable locations for the integration.

Step 2: Retrieve availability

Availability represents bookable time slots.

GET /commerce/{connection_id}/availability

Important:

• availability cannot be created or modified
• it reflects what the integration exposes

Key filters

• locationId
• startGte
• endLt
• size
• itemId
• userId

Example

const availabilities = await sdk.commerce.listCommerceAvailabilities(
  connectionId,
  {
    locationId: "loc_123",
    startGte: "2026-05-01T00:00:00Z",
    endLt: "2026-05-02T00:00:00Z",
    size: 4,
    itemId: "item_789",
    fields: [
      "location_id",
      "start_at",
      "end_at",
      "size",
      "item_id",
      "staff_user_id",
    ],
    limit: 50,
    offset: 0,
  }
);

Each result includes:

• start_at
• end_at
• location_id
• optional item_id
• optional staff_user_id

Step 3: Create a reservation

Reservations are created using:

POST /commerce/{connection_id}/reservation

TypeScript:

const reservation = await sdk.commerce.createCommerceReservation({
  connectionId,
  commerceReservation: {
    locationId: "loc_123",
    startAt: "2026-05-01T18:00:00Z",
    endAt: "2026-05-01T20:00:00Z",
    size: 2,
    guestName: "Jane Doe",
    guestEmail: "jane@example.com",
    guestPhone: "+1-555-1234",
    notes: "Window seat if possible",
    itemId: "table_7",
  },
});

Notes:

• all fields are optional in the unified schema
• integrations may require:
  • location_id
  • start_at

Step 4: Manage reservation lifecycle

Reservations move through a status lifecycle:

Key implementation detail:

• cancellation should typically be handled by updating status to CANCELLED
• deletion removes the record entirely

End-to-end booking example

A typical product flow:

1. user selects a location
2. product retrieves availability
3. user selects a time slot
4. product creates reservation
5. product tracks reservation status

This flow is consistent across integrations at the object level, even if capabilities differ.

What differs across integrations

While the object model is consistent, behavior is not.

Reservation support

Location support

• listing supported across all
• retrieval varies by integration

Review support

• OpenTable and Yelp: read-only
• others: not supported

Availability

• widely supported
• structure varies slightly
• webhook support limited

Designing for partial support

When building booking into your product:

Design for the minimum flow

• location → availability → create reservation

Treat advanced features as optional

• reservation retrieval
• updates
• deletion
• review workflows

Avoid assumptions

Do not assume:

• reservation lifecycle APIs exist
• all fields are writable
• webhook support is available

Monitoring bookings

Most booking integrations do not provide native webhook support.

Instead:

• Unified uses [virtual webhooks](/blog/unlock_real_time_data_with_virtual_webhooks) (polling-based)
• or you poll list endpoints directly

Important signals

• reservation status changes
• availability updates

Example approach

• poll reservations using startGte
• track status field transitions
• update UI accordingly

Key insight:

reservation status is the source of truth for booking state

Build once with the Unified Commerce API

Instead of building per integration:

• OpenTable API
• Yelp API
• SevenRooms API
• resOS API

You implement one booking flow:

• same objects
• same endpoints
• same filters

What changes:

• underlying integration behavior

What stays consistent:

• API surface
• data model
• implementation pattern

Unified routes each request directly to the underlying integration, without storing customer data, so responses reflect the current state of the source platform.

Key takeaways

• booking integrations require multiple steps and vary significantly across integrations
• availability is read-only and used for discovery
• reservations are the write path for bookings
• integration support differs beyond reservation creation
• reservation status defines lifecycle state
• a unified data model removes most per-integration logic while still requiring awareness of provider limitations

→ Start your 30-day free trial

→ Book a demo