Shortcodes: Personalize Any Guest Text

A shortcode is a small token — {guest_first_name}, {property_name}, {gate_code} — that you write once and Haven fills in for each guest. Write "Welcome to {property_name}, {guest_first_name}!" and every guest reads a greeting addressed to them, at your property, without you touching the text again.

Anywhere you see the Shortcodes pill (the small braces chip beside a text field), that field supports them. Click the pill to search every shortcode available to you and insert it at the cursor. In the email editor the pill sits above the email, on the right, and inserts into the body or the subject line — whichever you last clicked in.

In an email, and in a text message, WhatsApp message or booking-thread post on Message automations, an inserted shortcode is a small pill that shows what it fills in for the property you are editing, with a { } mark so it never reads as typed text. Hover it to see which shortcode it is; its arrow swaps it, sets what to show when it is missing, or removes it. It turns amber and reads not set when that property has nothing saved for it.

Where shortcodes work

Emails and text messages — every CRM automation, booking message, and broadcast.
Guidebook text — check-in and checkout instructions, directions, house rules, Wi-Fi details, gate codes, "during your stay" notes, and the guest access section.
Welcome message — the Welcome card on your guide's Home tab.
Custom pages — page bodies, and the URL of a Link or Embed card (a per-stay smart-lock link like https://lock.example/?code={reservation_code} becomes the guest's real code before they tap it).
Guest tasks — custom pre-arrival steps, including their links.
Guest forms and polls — the intro, question prompts, hints, and thank-you screen.
Rental agreements — anywhere in the agreement body. See below for how signing works.
Welcome booklet — printed booklets resolve your property-level shortcodes when the document is generated.

The four sources

Haven built-ins. Reservation facts Haven already knows: {guest_first_name}, {guest_name}, {guest_email}, {guest_phone}, {guest_phone_last4}, {property_name}, {check_in_date}, {check_in_time}, {check_out_date}, {check_out_time}, {stay_dates}, {num_nights}, {num_guests}, {num_pets}, {paid_upgrades}, {balance_amount}, {balance_due_date}, {early_late_offer}, {host_first_name}, {guidebook_url}, {feedback_url} (the stay's review form), {rental_agreement_url} (opens the agreement to sign), and more. These resolve per reservation with no setup. {check_in_time} is the property's arrival: a clock such as 4:00 PM, a window such as 4:00 PM - 8:00 PM, or any time when guests may arrive any time that day. {check_out_time} is the property's check-out time, such as 11:00 AM. Both are blank when that property has no time set. {payment_next_step} is filled only on the reservation requested, approved and confirmed emails: one sentence on what happens with the guest's money — nothing charged yet and the saved card charged on approval, the saved card that couldn't be charged and the link to pay, or the saved card your approval charged. It is blank in every other email. {num_guests} is adults and children; infants are not counted. {num_pets} prints 0 when the booking has none. {paid_upgrades} lists the upgrades the guest paid for on that booking, such as Pool heating, Extra cleaning: add-ons bought at Haven checkout, in the guidebook or in your Host Co store, and upsells your PMS sold (such as Hospitable). Refunded and cancelled ones are left out, prices are never shown, and it is blank when the booking has none. {balance_amount} is the balance still to be charged on a booking with a payment schedule, in the booking's currency, such as $1,250.00, and {balance_due_date} is the day it is charged, such as November 2, 2026. Write "Your remaining balance of {balance_amount} is due on {balance_due_date}." and a guest who paid a deposit reads both figures. Both are blank once the balance is paid, for a booking paid in full, for one a channel (Airbnb, Vrbo, your PMS) collects, and for a request you approved that the guest has not paid yet. Give a fallback where a blank would read oddly: {balance_amount|0}. {early_late_offer} is one line inviting the guest to request early check-in or late checkout — Early check-in or late checkout? Request it here: followed by a short link that opens that stay's guidebook Offers tab — when the listing sells either and the guest does not already have it. It is blank when the listing sells neither, so put it on its own line. The booking-confirmed text and the guidebook welcome text end with it. {guidebook_url} resolves to a short link on your own domain — yourdomain.com/g/Km3Rt7xQw9Ab — that signs that one guest into that one stay. It is short enough for a text message and plain enough that Airbnb's and Vrbo's link checks leave it alone. A further guidebook you add to a listing — a cleaners' guide, an owner's manual — gets a built-in of its own, {cleaners_guide_url}, that resolves to that guidebook's link on the listing the message is about. See More Than One Guidebook per Listing.

The guest's loyalty points are built-ins too, and they are the guest's own: {points_balance} (their spendable points with your rewards program), {points_value} (what those points are worth off a stay) and {points_pending} (points that land when their stay ends). Each message fills in the points of the guest whose reservation it is about, in emails, texts, WhatsApp, inbox messages, the guidebook and agreements. A guest with no points, or one with no Haven account, resolves blank, so add a fallback: {points_balance|0}. See Loyalty Points.

Your custom shortcodes. Define your own keys — {parking_spot}, {trash_day}, {hoa_wifi}, {google_review_link} — under Settings → Shortcodes. The value you save is the default for every listing, so updating it updates every email, page, and agreement that uses the key. A listing that needs its own value — each property's Google review page, for example — gets one in the same place. Each custom shortcode in the list is marked Per listing or Every listing, so you can tell at a glance which ones change by listing. See below.

Guest answers. Anything a guest tells you on a guest form can be a shortcode: their arrival flight number, landing time, dietary needs. Open the form under Communication → Guest forms, and under the question choose Save the answer as a shortcode, then name it — {arrival_flight_number}. From then on that token fills in with what the guest on that reservation answered, exactly as they typed it. See Guest answers as shortcodes below.

PMS shortcodes. With a connected Hospitable or OwnerRez account, the picker lists that platform's shortcodes. For Hospitable that is its full catalog: the reservation code, check-in and checkout dates and times, guest names, counts and contact, price, cleaning fee, total and payout, the listing's name, address, rooms and descriptions, house rules and manual, Wi-Fi, and the smart lock code. Dates and times read the same as in Hospitable's own messages. For OwnerRez it is your custom fields, both booking fields ({BX…}) and property fields ({PX…}, such as a pool or gate code you keep on the property). Property fields are treated like door codes: they appear only once a guest's arrival details unlock, and in the guidebook simulator's unlocked stages. Values are fetched live from your PMS at send or view time, so a door code generated the morning of arrival still resolves correctly.

Some Hospitable codes appear greyed out, marked "Works in Hospitable messages only". Hospitable fills those inside its own messaging and does not share them: links other apps add to Hospitable (Chekin, Truvi, PetScreening, Autohost), Hospitable's own guest-portal and task links, and teammate and task details. For a Chekin or Truvi link, paste that app's link into the card or task directly, or save it as a custom shortcode.

How resolution behaves

A guest-answer shortcode the guest has not answered yet resolves to nothing, or to the fallback you set ({arrival_flight_number|not provided yet}). It is never shown to a guest as raw braces.
An unknown token stays visible as literal braces — that is your signal the key is misspelled or not defined, not a silent blank.
Sensitive per-stay values (door codes, lock links) resolve only for the guest on the reservation, honoring the same arrival-details reveal window and pre-arrival steps as the rest of the guide — in the guide, and in the emails and texts sent to that guest. Before then they resolve to nothing (or your fallback), and so do {wifi_info} and {check_in_details}. Public visitors never see them.
A Link or Embed card whose URL cannot fully resolve renders its empty state rather than a broken link.
Surfaces with no reservation attached — a printed booklet, a public page — resolve {property_name} and your custom shortcodes; per-guest tokens wait for a real stay. With no listing attached, a custom shortcode uses its default rather than any per-listing value.

Guest answers as shortcodes

Use this when you want to play a guest's own answer back to them — or to your team — without retyping it.

Open Communication → Guest forms, and open the form (or add one — the Arrival details template asks guests who want an airport transfer for their flight number and landing time, and already saves both as {arrival_flight_number} and {arrival_flight_time}).
Under the question, choose Save the answer as a shortcode. Haven suggests a name from the question; change it if you like. Save the form.
Insert the shortcode anywhere the Shortcodes pill appears. It is listed under Guest answers, and in Settings → Shortcodes.

A typical use: a custom automation a few days before check-in that reads "We have you arriving on flight {arrival_flight_number}, landing at {arrival_flight_time}. Reply if that has changed." Each guest reads their own answer, copied from the form — nothing is retyped, so nothing is mistyped.

How it behaves:

The answer belongs to the reservation. A message about one stay only ever shows that stay's guest's answer.
If the guest changes their answer on the form, later messages use the new one. Messages already sent are not rewritten.
Any question type works. A pick-one or pick-many question fills in the chosen options; a star rating reads "4 / 5".
Not answered yet: the shortcode is blank, or shows your fallback. In the email editor, set If it's missing, show on the pill.
The email preview shows a sample guest, so an unanswered shortcode appears there as its name in square brackets, e.g. [Arrival flight number].
Two forms can use the same shortcode name — for example a separate arrival form per listing. The guest's most recent answer is used.
A name cannot match a built-in shortcode or one of your custom shortcodes.
Broadcasts and marketing emails have no reservation behind them, so a guest answer has nothing to fill in there and is left blank.
Removing the shortcode from the question, or archiving the form, stops it filling in. The guests' answers themselves are kept.

A different value per listing

The key is defined once. The value can differ by listing.

While adding one: select Add shortcode. A side panel opens. Type the key, then under Fills in choose Different per listing. Type the default, then a value beside any listing that differs. Every listing is shown with its photo.

On a shortcode you already have:

Open Settings → Shortcodes.
Click the custom shortcode's row. A side panel opens with all of its settings. A Per listing shortcode shows every listing with its photo and its own value.
Type a value next to the listings that differ. Leave the rest blank — a blank field shows the default in grey, and that listing uses it.
To put a listing back on the default, clear its field or select the arrow beside it.

Changes save as you type. In the panel you can:

Find listings: search by listing name or value, show only listings with Own value or those that Use default, and pick a group when you have more than one.
Set several at once: tick the listings, type one value in the bar that appears, and select Apply. Use default on that bar clears the ticked listings instead.
Go back to one value: choose The same on every listing. Haven asks before it removes the listing values.

A shortcode that is the same everywhere opens to the same panel, where you edit its value, mark it Sensitive or add a note for your team. The key itself cannot change; delete the shortcode and add a new one to rename it.

Insert the same {google_review_link} in one email — the post-stay feedback email, for example — and the guest who stayed at a given listing gets that listing's link. A listing you never filled in gets the default.

{google_review_link} is the one shortcode you may not need to define at all. Once you connect a Google business (a listing's own under Reviews & Testimonials → Google business, or your default under Settings → Account & Profile → Account → Google business), Haven fills this token with the Google review page for the listing the guest stayed at. A value you save here still wins, so define it only when you want a different link.

Shortcodes in rental agreements

Agreements deserve a special note because they are legal documents. Write the template with tokens ("This agreement covers the stay of {guest_name} at {property_name}, arriving {check_in_date}"), and Haven substitutes real values when the guest opens the agreement in their guide. The signed record — the stored snapshot and the PDF — keeps the substituted text, so what the guest signed is exactly what they read, and a later change to a custom shortcode never rewrites an existing signature.

In the agreement editor shortcodes are called merge fields and show as labeled pills. Add one from Merge fields in the toolbar or by typing /. Agreements also have fields of their own that come from the booking: the cancellation policy, booking source, guest counts, check-in and check-out times, and more. See Merge fields for the full list.

The Preview button in the agreement editor shows a sample booking, so you can check the flow of a clause before a guest ever sees it.