---
title: "Direct Connect Architecture: Supplier to OTA and Metasearch"
description: "Design supplier-to-OTA/metasearch direct connections around ownership, mapping, retry and reconciliation."
slug: "direct-connect-architecture"
translationKey: "guide-direct-connect-architecture"
locale: "en"
type: "guide"
category: "architecture"
tags: ["travel-distribution","architecture","canonical-model"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
technicalVerifiedAt: "2026-09-26"
codeExampleStatus: "illustrative"
sources:
  - title: "Booking.com Connectivity APIs"
    url: "https://developers.booking.com/connectivity/docs"
  - title: "Google Hotel Prices"
    url: "https://developers.google.com/hotels/hotel-prices"
---
Direct Connect is not a company category; it is an integration topology in which two systems connect without requiring an intermediary distribution hub. Hotel/CRS → OTA, hotel/CRS → metasearch and airline → seller are common examples.

## Core flow

```text
Source System
  → Canonical Adapter
  → Partner API
  ← Ack / Reservation / Order
  → Reconciliation
```

## Ownership

Define the source of truth per field. Property/room identity, ARI, restrictions, booking and payment state do not have to be owned by the same system.

## Mapping and state

Map partner IDs into canonical identities and retain delta semantics, idempotency keys, source timestamps and versions. HTTP 200 alone does not prove downstream business state is correct.

## Retry and reconciliation

A create/update timeout can leave state unknown. Blind retries can create duplicate bookings or duplicate inventory mutations, so a lookup/reconciliation path is required.

## When to use it

Direct connections can reduce hops and increase control, but they also move certification, partner-specific maintenance and 24/7 operational responsibility directly onto your team.


## Failure modes

- duplicate booking retry after provider timeout,
- losing provider-specific identity/state during canonicalization,
- local booking state diverging from provider state,
- mapping drift causing incorrect property/rate matches,
- applying webhook/polling evidence out of order.

## Observability

Track provider success/error rate, p95/p99 latency, UNKNOWN bookings, reconciliation age, mapping failures and duplicate-prevention hits.

## Production checklist

- provider adapter boundary,
- canonical request/response model,
- explicit timeout budget,
- idempotency,
- UNKNOWN + reconciliation path,
- preserve provider/source references,
- mapping/version strategy,
- provider-level metrics and traces.