Booking Transfers

Move a booking from this location to a linked sister location in one action. Service, extras, deposits, online payments, and form responses all transfer atomically — the customer's appointment moves intact, and Syntra issues confirmations from the receiving side. Built for businesses with multiple sites that share customers but run their own diaries.

Booking Transfers is a module — enable it from Modules > Booking Transfers and configure the linked locations there.

When to Use This

You operate two or more locations running independent Syntra accounts (each with its own staff, services, calendar, and customers), but customers occasionally need to switch sides — usually because:

• A staff member is unavailable at the original location
• A customer is travelling and wants to be seen at the closer site
• The original location is closing on a holiday and the sister site is still open
• A specialist treatment is offered at one site only

Without this module, transferring would mean cancelling the booking at one location, manually creating it at the other, re-collecting the deposit, re-sending the consent form, and asking the customer to re-confirm. Booking Transfers does it all in one click.

---

How It Works

1. Pair two locations — each side adds the other as a linked location and the two sides exchange a shared secret
2. Map services and extras — Syntra discovers each side's catalogue and helps you map "Botox 1 area" on Location A to "Botox — 1 site" on Location B
3. Transfer a booking — open any booking, pick the destination location, choose a slot, click Transfer
4. The receiving side checks slot availability — if the slot is free, it creates a mirror booking with everything intact
5. The original booking is hard-deleted at the source — the booking lives at exactly one location at any given time
6. Confirmations go out from the receiving side to the customer, using their branding and contact details

The two locations communicate over an HMAC-signed HTTP channel. Every request is authenticated with the shared secret, every payload carries an idempotency key to prevent replays, and the protocol is versioned for forward compatibility.

---

What Transfers

When a booking is transferred, the receiving side inherits:

Category	What's transferred
Customer	Name, email, phone, timezone — created or matched on the receiving side
Service	Mapped to the equivalent service in the receiving catalogue
Time slot	The new start and end time you picked at transfer
Extras	Each extra mapped to the equivalent extra at the destination, with quantity and original price preserved
Form responses	Any intake form answers the customer submitted
Pricing	Service price, deposit amount, tax, currency, and final paid status
Online payment	Payment intent ID, saved payment method ID, card brand, and last four — recipients see "card on file" continuity
Notes	Internal booking notes

What does not transfer:

• Staff assignment (the receiving location has its own team)
• Treatment notes / clinical records (these stay in the originating account for retention)
• Communications history (each location keeps its own conversation log)

---

Pairing Two Locations

Pairing is a one-time setup, done from Modules > Booking Transfers > Settings on both sides.

1. On Location A, click Add location
2. Enter a label for the linked side (e.g., "Mayfair Branch")
3. Enter the base URL of the linked location's Syntra installation
4. Click the regenerate button to generate a shared secret, then copy it
5. On Location B, also click Add location, enter Location A's label and base URL, and paste the same secret
6. On either side, click Test connection — Syntra performs a signed ping and reports the catalogue summary if it succeeds

Both sides must use the identical secret. If you regenerate the secret on one side, you must paste the new value on the other.

A connection test that succeeds shows:

• A green Reachable badge
• The remote location's display name
• A catalogue summary — the count of services and extras visible at the remote
• A paired badge once the link has exchanged identifiers in both directions

A failed test shows the error inline (HTTP code, message, or specific error code from the remote) and a red Unreachable badge.

---

Catalogue Mapping

For a transfer to land cleanly, Syntra needs to know which service on the source side corresponds to which service on the destination side. Same for extras. The two locations rarely have identical IDs — even if your service names match, the underlying records are different.

After a successful Test connection, the settings panel shows three counts per catalogue type (services and extras):

Indicator	Meaning
Matched	Items where Syntra found a confident match (typically by name + price)
Unmatched	Items on this side that have no obvious counterpart on the remote — needs your manual override
Remote-only	Items the remote has that you don't — informational, no action needed

For each unmatched item, pick the correct remote counterpart from the dropdown. Leave it blank to forbid transfers of bookings that involve that item — Syntra will refuse rather than fall back to a wrong mapping.

This mapping is per direction — you'll typically configure it on both sides.

---

Transferring a Booking

From any booking detail view, open the actions menu and pick Transfer to another location. Syntra opens the transfer dialog:

1. Pick the destination location from your linked list (only enabled, paired locations are shown)
2. Pick a new start time — defaults to the original time at the destination's timezone
3. Syntra checks slot availability at the destination as you adjust the time. The dialog shows:
   • Available — green badge, transfer enabled
   • Unavailable — red badge with the reason from the remote (booked, outside hours, agent unavailable)
4. Confirm the transfer

Syntra:

1. Sends the signed inbound payload to the destination
2. The destination creates the mirror booking (or reuses an existing matching one if the idempotency key has been seen)
3. On success, the destination returns the target booking ID and target reference
4. The source side hard-deletes the original booking
5. The customer receives a confirmation from the destination location with its branding

You're shown a toast with the new reference and a link to the destination booking on the receiving side.

---

Failure Modes & Safety

The transfer protocol is built to be safe under partial failure. Every error condition has a deterministic response:

Error	What happens
Unauthorized	The shared secret didn't validate. The remote rejects the request and nothing changes on either side.
Replay detected	The idempotency key has been seen before. The remote returns the existing target booking — no double-booking is ever created.
Service unmappable	The booking's service has no mapping at the destination. The remote refuses the transfer; the source booking is untouched.
Extra unmappable	An extra on the booking has no mapping. Same as above — refused, source untouched.
Slot unavailable	The chosen time slot conflicts at the destination. Refused; source untouched.
Invalid payload	The wire format is malformed (usually a protocol-version mismatch). Refused; source untouched.
Internal error	An unexpected error at the destination. Refused; source untouched.

The source booking is only deleted after the destination confirms creation. If anything goes wrong upstream, the booking stays exactly where it was.

Idempotency

Each transfer carries an idempotency key based on the source booking ID. If the same key arrives twice — say, the first call hung and the source retried — the destination returns the existing target booking instead of creating a duplicate. You can never accidentally double-book a customer through a network glitch.

Protocol versioning

The wire protocol carries a version (currently v1). If the two sides ever drift out of sync because of an update, the receiving side returns invalid_payload and refuses the transfer — never silently corrupts data. Both sides should run the same Syntra version.

---

Related Guides