Messaging Integration
A messaging channel bridges a conversation surface HolidayHero does not natively speak — your PMS inbox, an OTA's guest messaging, your own chat product — into HolidayHero.
Once bridged, those threads land in the same inbox as everything else. The same operators answer them, the same AI can answer them, the same templates and automations reach them. The guest carries on messaging where they already were and never learns anything changed.
This is part of the Connect API. Read that first if you have not.
Who this is for
You have guests messaging you somewhere HolidayHero cannot see, and you want that traffic in one place. Typically:
A PMS or channel manager whose inbox already aggregates guest messages.
An OTA integration, where the booking platform owns the messaging relationship.
Your own product, if you have a guest chat surface you want to keep but not staff separately.
If you just want to send guests messages over email, SMS or WhatsApp, you do not need any of this — those are built in and configured in the dashboard.
What you get
One inbox. Threads from your surface sit alongside every other conversation, with the same status, assignment and handover behaviour.
The AI answers them. Subject to the same rules and the same handover-to-human logic as any other channel — including escalation when a guest's tone sours.
Templates reach them. Operators build scheduled and triggered messages against your channel the same way they do for any other.
Attribution stays honest. A guest's message reads as the guest, not as your integration. This matters more than it sounds: it is what makes the AI treat it as something to answer.
How it works
Traffic runs in both directions, and the two directions work differently.
Outbound — HolidayHero to the guest. We call you. When something should be sent on your channel, we ask you first whether the reservation is yours, and then hand you the message to deliver.
We have to ask, rather than work it out locally, because we genuinely cannot know. A reservation records which platform a booking originated on, but that is analytics — it does not mean the messaging relationship is yours. You are the only party who can answer "is this thread mine", so we ask.
Inbound — the guest to HolidayHero. You call us, over the normal Connect API. When a guest messages on your side, you open the thread (or attach to the existing one) and post the message.
The channel is yours: only your application can open conversations on it or read its messages. No other integration, and no other customer, can touch it.
What you need to have
A publicly reachable HTTPS endpoint that we can call. Private, loopback and link-local addresses are refused, and we do not follow redirects.
Signature verification. Every request we send is signed with your application secret over a timestamped payload. It is the same scheme as our event delivery, so if you already verify those, you already have the code.
Somewhere to keep two identifiers — ours for the thread and the message, yours for the same. You will need the mapping in both directions.
Registration of your endpoint is not self-service today. You send us the URL and we set it on your application. Until it is set, nothing calls you — which means you can build and test the rest of the integration long before the endpoint goes live.
Decisions to get right early
These are cheap to decide now and expensive to change later.
Who your channel addresses. Most PMS and OTA channels address the person who made the booking, not the individual guests on it. Declare this when you create the channel — operators are held to it, and getting it wrong means they cannot build the templates you are expecting.
"Not my reservation" is permanent. When you tell us a reservation is not yours, we believe you and stop asking, for that reservation, for good. A misdeployed endpoint that answers "not mine" by accident will silently suppress that guest's messages for their entire stay. Answer "not mine" only when you mean it; answer with a server error when something is temporarily broken, and we will ask again.
Retries will happen. Deliveries carry an idempotency key and are retried on failure. Accepting the same key twice must not send the guest two messages.
Echoes. If your platform relays messages it receives back out again, our own outbound message will come back to us as an inbound guest message — and the AI will answer itself. Return your identifier for each message we hand you, then drop anything carrying it on the way back in. Without that identifier an echo is indistinguishable from a real guest.
What we give you
The full contract — exact requests, responses, headers, status-code semantics, and reference signature-verification code in PHP and Node. Ask us and we will send it.
A test workspace, so you can drive real message templates at your endpoint without a real guest on the other end.
A failure notification. If your endpoint starts failing, we email the developer address on your application rather than leaving it to be noticed.
Where to start
Tell us which surface you want to bridge and who it addresses — the booker or individual guests. We will confirm the shape, send you the contract, and set you up with an application and a test workspace.
Last updated