Integration setup

An API key grants access. It does not install an app, connect a partner account or prove that bookings are syncing.

Available setup paths

Calendar subscription

1. In Developer, find Calendar subscription, name the link (for example the device or person it is for) and, for appointments, choose all staff or one staff member.
2. Copy the link straight away. It is shown once. Anyone with it can see the schedule, so share it only with the person it is for.
3. On an iPhone or Mac, press Open in calendar app. In Outlook, use Add calendar, then Subscribe from web. In Google Calendar, use Other calendars, then From URL.
4. The feed shows booking times, the service or party size, and the staff member or table, from 30 days back to 180 days ahead. It never includes guest names, contact details or notes. Cancelled bookings drop out on the next refresh.
5. The link reads Waiting for a calendar app to subscribe until a calendar first fetches it. To stop a link working, turn it off; make a new one if it was shared by mistake.

n8n availability workflow

1. Download the workflow and import it into n8n using Import from File.
2. In Gaplessly Developer, create a Test (sandbox) key with organization:read and availability:read. The n8n card's quick key button creates a live read-only key; use the key form for sandbox testing.
3. In n8n, create a Header Auth credential. Set Name to Authorization and Value to Bearer YOUR_KEY. Choose that credential in both HTTP Request nodes. Keep the key in credentials, never in the workflow JSON.
4. Open Inputs. For a restaurant, set partySize. For appointments, set serviceId and optionally providerId from your Gaplessly service and staff records. Set date to YYYY-MM-DD, or leave it blank for today in the business timezone.
5. Execute the workflow. The last node returns days, available slots and reasons a day is unavailable. An empty slot list can be a successful response; a 401 or 403 is not.
6. When the sandbox check passes, select a live key for the intended organization. This workflow only checks availability; it does not sync a calendar or make bookings.

n8n booking events workflow

Download the events workflow. It receives Gaplessly's signed webhooks, checks each one and routes it by event type: booking.created, booking.updated, booking.cancelled, guest.created, guest.merged, the ping from a test send, and anything else.

1. Import the workflow. On self-hosted n8n, start n8n with NODE_FUNCTION_ALLOW_BUILTIN=crypto so the Code node can compute the signature. n8n Cloud already allows it.
2. Activate the workflow and copy the Production URL from the Gaplessly webhook node. It must be a public https address.
3. In Gaplessly Developer, under Webhooks, add that address and choose the events. Copy the signing secret (it starts with whsec_). It is shown once. To hear only sandbox bookings, register the address with a Test key through POST /api/v1/webhooks instead, which returns the secret the same way.
4. Store the secret in n8n as a Variable or an environment variable named GAPLESSLY_WEBHOOK_SECRET. A Code node cannot read n8n credentials, so a credential will not work here. Never paste the secret into the workflow itself, where it would travel with every export.
5. Leave Raw Body switched on in the webhook node. The signature covers the exact bytes we sent. Parsed and re-encoded JSON can differ by a single character and then fails the check.
6. Send a test event from Developer. It arrives on the ping output. Then replace each placeholder step with your own.

What the Verify signature step does:

• Recomputes the HMAC-SHA256 of the timestamp, a full stop and the raw body with your secret, and compares it with the v1 value in the Gaplessly-Signature header in constant time.
• Refuses a timestamp more than five minutes from n8n's clock, so a captured request cannot be replayed later. Keep the n8n server's clock in sync.
• Answers 401 to a tampered, stale or unsigned request, which then goes nowhere. It answers 500 when the secret or raw body is missing, so our retries resume once you fix the setup.
• Remembers accepted event ids for three days in the workflow's static data and answers a retry of one with 200 without running it again. We retry a failed delivery with the same event id for about a day. Static data is kept only for the active workflow's production URL, not for test runs, and two copies of one event arriving at the same moment can both run, so keep later steps safe to repeat.

The workflow answers us as soon as an event is verified, inside our 8 second deadline. A step that fails after that is not retried by Gaplessly; give the workflow an n8n Error Workflow so you hear about it. Events can arrive out of order, and each one carries the booking as it was when it was sent. Use data.object.id as the booking reference.

n8n create booking workflow

Download the create workflow. It books a table or an appointment, whichever your organization runs.

1. Create a key with organization:read and reservations:write (restaurants) or appointments:write (appointments). Start with a Test (sandbox) key. Add it as a Header Auth credential, as for the availability workflow, and select it on both HTTP Request nodes. On self-hosted n8n, allow the crypto module as above.
2. Replace Run manually with your real trigger and fill Inputs from it: startsAt, partySize (restaurants) or serviceId and providerId (appointments), and the guest's name, email and phone. Some businesses require a phone number.
3. Set sourceEventId to a stable id from the source event, such as a form submission id. A retry with the same id replays the first answer instead of booking twice. Use a new id for every booking you intend to make.
4. Give startsAt in the business's local time, YYYY-MM-DDTHH:MM, with no offset. A time ending in Z or an offset is refused before anything is sent.

Only a 201 response counts as booked. Its status is confirmed, or pending for a large party the venue still has to accept. Every other answer fails the run on purpose: payment_required (402) means the business takes a deposit or card that only the guest can give, so nothing was booked and the error carries the link to send the guest; a 409 means the time is taken or the request conflicts. A reused sourceEventId replays the same refusal, so choose a new one for a new attempt.

n8n bookings to Google Sheets workflow

Download the Sheets workflow. It keeps one row per booking up to date from verified booking events.

1. Set it up as the events workflow above, with its own webhook address and secret, subscribed to booking.created, booking.updated and booking.cancelled.
2. Create a sheet whose header row is: bookingId, kind, status, startsAt, endsAt, partySize, serviceId, providerId, tableId, depositStatus, bookedAt, lastEventType, lastEventId, lastEventAt.
3. In Upsert booking row, choose your Google Sheets credential, the document and the sheet.

Rows are written with Append or Update, matched on bookingId, so a booking keeps a single row however many events or retries arrive, and the latest status replaces the old one. Times are the venue's local time. Guest names, emails, phone numbers and notes are not written by default; add them in Booking row only if everyone who can open the sheet may see guest contact details.

n8n booking demand to Deputy workflow

Download the Deputy workflow. Every hour it reads the next 14 days of bookings and sends Deputy one value per hour of your venue's day: booked covers for a restaurant, booked hours for appointments. Deputy shows them beside its own sales and forecasts while you build the roster, so a busy Saturday is visible before the till sees it.

1. In Gaplessly Developer, create a key with organization:read and reservations:read (restaurant) or appointments:read (appointments). In n8n, make a Header Auth credential with Name Authorization and Value Bearer YOUR_KEY, and choose it in Read organization and Read bookings.
2. In Deputy, create a custom metric in Business Insights named BookedCovers (or BookedHours for appointments). Deputy refuses data for a metric it does not have.
3. In Deputy, create an API access token for your install. Make a second Header Auth credential with Name Authorization and Value Bearer followed by that token, and choose it in Send to Deputy.
4. Add n8n Variables: DEPUTY_INSTALL (your Deputy address, for example https://yourvenue.au.deputy.com), DEPUTY_AREA_ID and DEPUTY_LOCATION_ID (the Deputy area and location to file the numbers under), and DEPUTY_METRIC if you named the metric something else.
5. Run it once by hand, check the numbers in Deputy, then activate it.

Each hour is sent with the same reference every run, so a booking that is cancelled or moved updates Deputy's number instead of adding to it, and an hour that loses its last booking goes back to zero. Cancelled and no-show bookings are left out. Only counts and hours leave Gaplessly: no guest names, contact details or notes. We test the workflow's code steps in our test suite but have not run it against a live Deputy account.

Make recipes

There is no Gaplessly app in Make. These recipes use Make's own HTTP module, and we have not run them in a Make account. Build and test them against a Test (sandbox) key first.

Check availability

1. Add an HTTP: Make a request module. URL https://gaplessly.com/api/v1/organization, method GET, header Authorization with the value Bearer followed by your key (organization:read and availability:read). Turn on Parse response. Where your plan offers it, keep the key in a Make keychain rather than typing it into the header.
2. Add a second HTTP module. URL https://gaplessly.com/api/v1/availability, method GET, the same header, and query string date (YYYY-MM-DD in the business timezone) plus partySize for a restaurant, or serviceId and optionally providerId for appointments. The first module's data.businessType says which.
3. The response lists days, available slots and the reason a day is unavailable. An empty slot list can be a successful answer.

Create a booking

1. Add a Tools: Set variable module named hash with the value sha256("gaplessly:make:create:" + your source event id), using a stable id from the trigger, never a random one.
2. Add an HTTP: Make a request module. URL https://gaplessly.com/api/v1/reservations (restaurants) or https://gaplessly.com/api/v1/appointments (appointments), method POST, body type Raw, content type JSON.
3. Headers: Authorization with Bearer followed by a key holding reservations:write or appointments:write, and Idempotency-Key built from hash in the UUID shape: substring(hash; 0; 8), a hyphen, substring(hash; 8; 12), a hyphen, substring(hash; 12; 16), a hyphen, substring(hash; 16; 20), a hyphen, substring(hash; 20; 32).
4. Body: startsAt in local time (YYYY-MM-DDTHH:MM, no offset), customer with name, email and phone, and partySize for a table, or serviceId and providerId for an appointment.
5. Keep Evaluate all states as errors on, so a 402 payment_required or a 409 stops the scenario instead of passing as a success. Only a 201 is a booking. Route the error to a handler that sends the guest the bookingUrl from a 402.

Receiving events in Make

Make's Custom webhook module can receive our events, but we cannot tell you how to verify them there. The check needs the exact raw body, an HMAC compared in constant time and a five-minute replay window, and we have not confirmed that a Make scenario can do all three. Gaplessly does not send a shared secret header either, so a filter on a header proves nothing about who sent a request. Anyone who learns the webhook address can post a fake event to it. To receive events with verification, use the n8n events workflow or the Zapier connector, and keep Make for availability and create calls.

Zapier private testing

The connector needs to be registered in a Gaplessly-owned Zapier developer account and shared privately before you can select it in the Zap editor. Creating a key here does not make a Zapier app appear. There is no public installation link yet.

Once private access is provided, create a Zapier-labelled sandbox key. Include organization:read and the scopes needed by the steps: availability:read for availability; reservations:read and reservations:write for table bookings; appointments:read and appointments:write for appointments; webhooks:write plus the relevant read scope for booking events; clients:read for guest events.

The Booking or Guest Event trigger subscribes when a Zap is enabled and removes its subscription when disabled. Each key can have three subscriptions, within the organization's total of ten. One trigger offers created, updated, cancelled and guest-created events. The Event ID identifies a notification; Object ID identifies the booking or guest. Map Object ID into reschedule and cancel steps.

For Create Booking, map a stable source event ID, unique to the intended booking. Keep it unchanged on retries and use a different ID for each new booking. Enter start times in the business's local timezone (YYYY-MM-DDTHH:MM), with no UTC offset. A booking that requires payment or card collection fails with payment_required; no unpaid booking is created. Complete those bookings through the guest booking page.

Test create, reschedule, cancel and a webhook delivery in the sandbox before using live credentials. Check webhook deliveries in Developer and the actual Zap run, since an accepted HTTP delivery alone does not prove that downstream steps succeeded.

Partner onboarding

Contact the prospective partner to establish whether they support Gaplessly and how they onboard a venue. Do not assume that a partner accepts a Gaplessly key because it integrates with another booking platform. Share a scoped sandbox credential through the partner's agreed secure setup only after support is established.

A Key created badge reports credential provisioning only. Revoke obsolete credentials in Developer. Sandbox keys never count as live setup. Google booking links are separate from Reserve with Google, which requires an approved Actions Center integration.