Overview

Before starting a Vendor API 3.0 integration, get the overall structure and the preparation items straight.

Endpoints at a glance

38 HUB APIs + 5 vendor APIs (webhooks) = 43 in total

HUB API conventions: POST to create, PATCH to update, GET to read, with 200 OK on success.

Vendor APIs use different methods depending on the action: PUT for booking confirmation and modification, POST for creation and cancellation, and GET for the policy lookup.

Direction and roles (read this first)

Channels are either Plus channels (channel_type=hub) or direct channels (channel_type=cms). In the HUB API the vendor is the client; in the vendor API (webhooks) the vendor is the server.

API	Direction	What the vendor implements
HUB API	Vendor → ONDA	Client — calls /gds/vendor/... (content push, ARI push, channels, booking and settlement lookups)
Vendor API (webhooks)	ONDA → Vendor	Server — exposes endpoints ONDA calls (booking processing, policy lookup)

Channel types — Plus and direct

Sales channels connected to ONDA fall into two kinds, depending on who operates the channel. This distinction drives everything from the opening procedure to how bookings are processed.

	Plus channel	Direct channel
channel_type	hub	cms
In one line	One contract with ONDA sells across every channel connected to ONDA	The property contracts with the OTA directly and runs the channel itself
Registration, operation, settlement	Handled by ONDA	Handled by the property

Who handles each step?

Step	Plus channel	Direct channel
Rate and availability sync	ONDA	ONDA
Channel contract	ONDA	The property
Listing and content distribution	ONDA	The property
Settlement and accounting	ONDA	The property
Booking confirmation	ONDA validates, then confirms	Created immediately, without validation

Rate and availability sync goes through ONDA in both cases. The content and ARI push code a vendor writes is identical regardless of channel type.

Plus channel — everything from contract to settlement goes through ONDA.

Direct channel — only rates and availability go through ONDA; the property handles the contract and settlement with the channel directly.

What differs in the API?

Aspect	Plus channel	Direct channel
Channel opening	Just submit a request — Plus Channel Opening	Requires pre-mapping steps, channel settings, and mapping — Direct Legacy Channel Opening
Mapping API	Not used (ONDA manages it)	PATCH .../mappings required
Per-channel settings	Not used	PATCH .../settings
Booking validation	ONDA and the vendor each validate	None — accepted unconditionally
Booking modification (modify)	Soft changes only	Both soft and hard changes
Product type	overnight	overnight (channels that support day-use also send dayuse)

Channel type is per channel

It is decided per channel, not per property. One property can run some channels as Plus and others as direct. Check channel_type in the GET /gds/vendor/channels response.

For an explanation from the property operator's point of view, see Introducing the ONDA Plus channel manager.

Integration lifecycle

Preparation checklist

• Settle the base URL for HUB API calls and separate staging from production
• Provide the receiving endpoints and base URL for the vendor API (webhooks)
• Authentication: send the vendor access token in the Authorization header on HUB API calls
• Authentication: implement token and signature verification for incoming ONDA requests to the vendor API
• Fetch the code catalog and build the code mapping table into your system

Pre-launch integration testing

• First-sync end to end: create property → room type → rate plan model → rate plan, then push rates, business days, and availability, and confirm they reach the channel
• Full flow on a Plus channel: opening → booking → confirmation → cancellation
• Flow on a direct channel (legacy and OAuth): mapping → ON request → booking
• Token expiry and renewal, plus error handling for 4xx and 5xx responses
• Idempotency and retry policy (no duplicate bookings or duplicate cancellations)
• Sign-off to move to production after staging verification

Operational and business decisions

Separate from the API work, these are the items to agree on with ONDA before going live. Items marked 📘 have a dedicated guide.

Area	Item	What to confirm
Content and language	Multilingual content	Whether languages other than Korean are used, and how to send them
Content and language	Special characters in property name and description	Strip characters that cannot be displayed
Content and language	Special characters in room name and description	Strip characters that cannot be displayed
Scope and products	Property scope	Selling overseas properties, or domestic only
Scope and products	Product structure	Selling by room, or by package (rate plan) per room
Rates and availability	Extra occupancy charges	Whether extra occupancy charges can be sent
Rates and availability	Push horizon	How many months of rates and availability can be sent
Booking structure	Booking number structure 📘	One gds_booking_number to many gds_sub_booking_number. Vendor bookings are created against gds_sub_booking_number
Booking structure	Plus channel booking validation	Checks for availability, matching rates, active sales status, and so on
Cancellation	Per-date refund policy 📘	Whether policies differ by date (Refund Policy)
Vouchers	Booking vouchers	The vendor sends confirmation and cancellation vouchers to the property directly

Booking number structure

Field	Description
gds_booking_number	ONDA Hub booking number
gds_sub_booking_number	ONDA Hub sub-booking number. Vendor bookings are created against this value
channel_booking_number	Sales channel booking number. The key is omitted entirely when the sales channel does not supply its own booking number, so do not treat it as always present

One gds_booking_number corresponds to many gds_sub_booking_number values, and the vendor's own booking_number maps one-to-one with gds_sub_booking_number.