Delivery log: verify what was sent to channels

Esta página aún no está disponible en tu idioma.


Why	Check what actually left the PMS for the channels and how delivery went — when a channel does not show updated prices or a booking.
Who	An administrator sorting out a mismatch between the PMS and a channel.
What you’ll get	You can read the outgoing events log and the error code, and you know how to start a resend.
Limitations	There is no “resend this entry” button in the log — a resend starts for one channel or for all channels at once.

Every change — a price, availability, a new booking, or a cancellation — leaves for the connected channels as events. The delivery log shows every push and its result: when a channel “does not see” an update, this is where you check whether the change was sent at all and how delivery ended.

This article covers opening the log, reading an entry, understanding the cause of a failure, and starting a resend.

Why the log exists

The PMS and the channel are two different systems, and a stream of outgoing events connects them: every change to prices, availability, or bookings travels to the channel as an event. The log records every push and keeps what matters about it: the channel, the period, and the status.

That is enough to tell which side the problem is on:

the push was delivered — the PMS did its part, and the question is now for the channel;
there is no entry in the log — the change never left the PMS;
delivery failed — the reason is recorded on the entry itself, and we will get to it below.

Open the log

Open the Channel Manager in the left menu.
Go to the “Events” tab.
Open the “Outgoing” sub-tab — this is the delivery log.

Result: all outgoing events are in front of you; the “All channels”, “All event types”, and “All statuses” filters plus the “Search by ID/type/error” search narrow the list down to the entry you need.

Two more sub-tabs sit next to it: “Incoming” — what the channel sent your way, and the “Action log” — who changed which settings. For sorting out delivery, “Outgoing” is the one you need.

Read an entry

Each log entry has its own columns:

“Time” — when the event left the PMS.
“Channel” — where it was going: the channel’s name and the property ID in it.
“Event type” — what was being sent.
“Period” — the dates the update concerned.
“Status” — how delivery ended.
“Attempts” — how many times the system tried to deliver.
“Evidence” and “Error” — “Open” buttons: the event body and the reason for the failure.

There are three event types: prices and availability travel as one type, bookings as two.

availability.update — an availability and price update;
reservation.export.create — a booking created;
reservation.export.cancel — a booking canceled.

The log uses two statuses:

DONE — delivered: the channel accepted the push;
FAILED — not delivered: the push did not get through — sort it out through the error, the next section.

Result: the “Status” + “Attempts” pair answers the main question — whether the update was delivered and how many times the system tried.

Understand the error

Find the entry with the FAILED status.
In the “Error” column, press “Open”.
In the “Outgoing event error body” dialog, read the reason code; for a long body, the “Search within the error body” search is handier.

The reason code is the most concrete hint an entry has. For example, “the channel does not know a property with this ID” means the external property ID does not match — check the connection settings: the property ID field you filled in when connecting the channel. How to read the connection status itself — in the article Channel connection statuses: active, paused, error.

Resend

There is no “resend” button on an individual log entry. A resend starts one level up:

to all channels at once — on the “Channels” tab, open the “Functions” menu and choose “Send updates to all OTA”;
to one channel — press the “Start sending to the selected channel” icon on the card of the channel you need.

Two limits. On a channel with the “Paused” status the sending icon is inactive — bring the channel back to an active status first (how — in the channel statuses article linked above). And alongside your manual sends, the system repeats failed deliveries on its own: how many attempts have already been made is visible in the “Attempts” column.

Result: there is no per-entry resend — the update goes out again to the whole channel or to all channels at once; between your sends, the system makes attempts of its own.

The “Channel errors” tab

When the same problem repeats, going through the log entry by entry is tedious. Repeats have a separate tab: “Channel errors” — a summary of recurring problems across all channels.

Filters — “Status”, “Channel code”, “Direction”.
Columns — from status and channel (“Status”, “Last repetition”, “Channel”, “Direction”) to the essence of the problem (“Reason”) and its scale (“Repetitions”, “Linked bookings”).

An empty tab reading “No channel errors found” is good news: the system sees no recurring problems.