—Customizing your packet
Every property starts with one default packet, and on Free that's all you get. Solo and above lift the cap so the same property can run different rules and fees for different kinds of stays — weekend vs weeklong, peak vs off-season, whole-home vs single-room. Each reservation points at one packet; you pick which.
A single property often serves a few distinct guest patterns. Common splits hosts use:
The point is to keep one cleanly-disclosed packet per scenario — not to soften a rule the platform requires in the listing.
Two surfaces, depending on whether you're thinking property-first or portfolio-first:
/app/#/packets — the global Packets page (sidebar link, directly under Properties). One table of every packet across every property you own. Useful when you want to scan the whole portfolio, find a specific variant by name, or jump straight into editing without bouncing through the property page first./app/#/properties/<id>/packets — the per-property Manage packets page (Property → Packets link in the subnav). Scoped to one property, with the per-row actions for setting a default, archiving, restoring, renaming, duplicating, and deleting.Both pages show the same packet rows. Pick whichever matches the mental model you start with — both routes open the same editor when you click into a packet.
From the global Packets page click + New packet at the top (after picking a target property), or open the property and click Packets in the subnav, then + New packet.
On Free, the second-packet button still appears but the POST returns a plan-limit error — the upgrade modal opens with the Solo CTA.
From the same Manage packets page, the Duplicate action on any row lets you pick a target property. Useful when you set up rules carefully on one listing and want them mirrored to a sibling — a guesthouse next door, a second unit in the same building. The copy lands as a non-default packet on the target and opens in the editor so you can adjust local details (parking, the door code).
Exactly one packet on a property is the default. New reservations that don't pick a packet inherit it; calendar-synced bookings inherit it; the cron picks it when auto-send fires.
To switch the default, open Manage packets and click Set default on any non-archived, non-default row. The old default loses the flag automatically — they're mutually exclusive at the database level.
When you create a reservation manually, the Packet select on the New reservation form lists every active packet on the property; the default is pre-selected. Pick a variant when the stay calls for it (e.g. "Weekend" for a 2-night NYE stay).
On an unsigned reservation, the packet can still be changed from the reservation detail page — Actions ▾ → Change packet. Once the guest signs, the packet is frozen into the certificate snapshot and can't change.
The certificate is the legal artifact — it records the exact rules and fees the guest acknowledged at sign time. Later edits to the packet (or even archiving it) never reach back into a signed certificate. The acknowledgment hash and content are immutable.
That means you can refine your rules and fees as you learn — without worrying that a past stay's evidence will shift under you.
Archive a packet when you want to stop using it but past reservations still reference it. The variant goes to the archived section, the host can't pick it on new reservations, and any reservation that already points at it keeps working.
Delete only works when the row's reservation count is zero. If any reservation (past or present) references it, the delete is blocked at both the UI and server — archive instead. Signed certificates are never affected either way.
Was this helpful?
Still stuck? Message us — we read every message and reply within a few hours on weekdays.