A bookings API that already knows your rules

Service durations, staff schedules, buffers, capacity limits, timezones. The API reads the same rules your storefront does, so the times it hands back are times a customer can actually book.

Read the API reference Talk to our team

REST · JSON · OpenAPI 3.1 · Included on the Enterprise plan

# Every slot here is one a customer could book right now
curl "https://app.getservicify.com/api/public/v1/events/5117/slots\
?from=2026-08-18&to=2026-08-22" \
  -H "Authorization: Bearer srv_live_a1b2c3d4"

{
  "eventId": 5117,
  "timezone": "America/Toronto",
  "slots": [
    {
      "startAt": "2026-08-20T14:00:00.000Z",
      "endAt": "2026-08-20T15:00:00.000Z",
      "startTime": "10:00 AM",
      "endTime": "11:00 AM",
      "availabilityId": 312,
      "availabilityName": "Dana R.",
      "remainingCapacity": 3,
      "variantId": "43219874512903"
    }
  ]
}

Booking looks simple until you build it

Writing the record is the easy part. Working out which times you are allowed to offer, and making sure one request never becomes two bookings, is where the weeks go.

A gap in a calendar is not an open slot

Before you can offer a time you need the service duration, the buffer on either side, the lead time, the booking cutoff, how many seats are left, and which staff are qualified to run it. Miss one and you offer times nobody can take.

Timezones break in production, not staging

Staff hours are local, customers are anywhere, and weekly schedules collide with one-off overrides on the Sunday the clocks change. You find out when someone shows up an hour early.

One timeout becomes two bookings

A booking write is not idempotent by nature. A single retried request can hold two slots, send two confirmations, and put two invites on a staff calendar. You need replay protection before launch, not after the first complaint.

One booking sets off eight other things

A calendar hold, a confirmation email, an SMS, a Shopify order, a customer record, a webhook, a waitlist promotion, and tags. Write around that workflow and your API path drifts from the one your storefront uses.

Two calls and it's booked

Ask what's open. Send one back with the customer. The timezone and capacity problems stay on our side.

Step 01

Ask what's open

One call runs the same scheduling engine as your storefront, against live bookings and current staff schedules. Nothing it returns is theoretical.

Step 02

Pick a slot

Each one arrives with the time, the staff member, the price variant, and the seats left. There is no mapping layer on your side.

Step 03

Send it back

Post the slot and the customer. That booking gets the same calendar hold, emails, and webhooks as one made on your storefront.

GET/events/{id}/slots

# Every slot here is one a customer could book right now
curl "https://app.getservicify.com/api/public/v1/events/5117/slots\
?from=2026-08-18&to=2026-08-22" \
  -H "Authorization: Bearer srv_live_a1b2c3d4"

{
  "eventId": 5117,
  "timezone": "America/Toronto",
  "slots": [
    {
      "startAt": "2026-08-20T14:00:00.000Z",
      "endAt": "2026-08-20T15:00:00.000Z",
      "startTime": "10:00 AM",
      "endTime": "11:00 AM",
      "availabilityId": 312,
      "availabilityName": "Dana R.",
      "remainingCapacity": 3,
      "variantId": "43219874512903"
    }
  ]
}

One entry per available staff member, already capacity-checked and priced. Up to 31 days per request.

All of this already works

Every line here is running in production for merchants taking bookings today. You inherit it, and you inherit the fixes.

Browse the full reference

Slot generation from duration, buffers, and lead time
Intersecting staff schedules with existing bookings
Recurring weekly hours plus per-date overrides
Timezone conversion and daylight saving boundaries
Group capacity and remaining-seat math
Double-booking prevention under concurrency
Confirmation, reminder, and cancellation emails
SMS notifications on the merchant's own settings
Google and Outlook calendar sync
Shopify order, variant, and price wiring
Waitlist promotion when a seat frees up
Refund handling on cancellation

What you can do with it

Anything a staff member can do in the admin, a script can do through the API.

Show real openings

Bookable times for any service, filtered by staff, capacity, and every policy the merchant has set.

Book, reschedule, cancel

Run the whole lifecycle, with refunds and customer notifications following the merchant's own settings.

Move work between staff

Assign a booking to a team member, or move it to someone else when the roster changes.

Send a reminder on demand

The same action as the Remind button in the admin, across whichever channels the service has enabled.

Publish staff schedules

Recurring weekly hours, plus one-off overrides for the days that break the pattern.

Pull booking data

Booking history and peak hours by local day and hour, for reporting or staffing decisions.

Safe for software running unattended

A script running at 3am cannot ask anyone whether it already sent that confirmation. It has to be able to work that out itself.

Find out what you're allowed to do

One call returns the shop, the granted scopes, and the server's clock, so a client can check its own permissions and correct for drift before it writes anything.

Scoped tokens, one shop each

Issue a separate token per integration with only the scopes it needs. A reporting job gets read access and nothing else.

Idempotency on writes

Required when creating a booking and recommended everywhere else. Replay a key with a different body and the request is rejected instead of applied twice.

Errors you can branch on

Every failure comes back in the same envelope, with a stable code to switch on and a message you can show a user.

What teams build with it

AI booking agents

An assistant can check what's genuinely open and book on a customer's behalf, instead of inventing times that don't exist.

Operations automation

Reschedule a full day when someone calls in sick, or send reminders to everyone booked before a busy weekend, in one script.

Custom booking surfaces

Put a kiosk, a mobile app, or a headless storefront on top of the same availability engine without forking the scheduling logic.

Reporting and sync

Feed bookings and peak-hour data into your warehouse or staffing model, and keep an internal system in step with the calendar.

Common questions

Most scheduling APIs return free/busy windows and leave you to work out what you can offer. This one runs the same engine your storefront runs, so every slot already accounts for service duration, buffers, lead time, staff eligibility, group capacity, and existing bookings. You send the slot back unchanged.

Yes. Writes go through the existing booking workflow rather than around it, so calendar reservations, confirmation and reminder notifications, webhooks, customer records, waitlist promotion, tags, and conflict detection all fire the same way they do when a customer books on your storefront.

The Easy Appointment Booking app installed on your Shopify store, on the Enterprise plan, and an API token generated from the admin. Tokens are scoped to one shop, so the API acts for a single merchant rather than across stores.

Two endpoints cover the common case: ask for open slots, then post one back with the customer. Reading availability needs no setup beyond a token, and the response is shaped so it can go straight into the booking call.

The server re-checks the slot and live capacity at write time, so a slot taken between your read and your write is rejected rather than overbooked. Idempotency keys cover the other half: a retried request replays the original result instead of creating a second booking.

A bearer token in the Authorization header. Each token carries named scopes such as bookings:create or reports:read, so you can hand out narrow credentials per integration and check what a token allows before using it.

Start with one call

Install the app, generate a scoped token in the admin, and ask for your first list of open slots. The API is included on the Enterprise plan.

Get started on Shopify Read the API reference

Keep exploring

Feature