Guide

Acuity Scheduling API Alternatives

Acuity's API manages your Acuity account, not scheduling embedded in your product. Compare Cal.com, the Calendly API, and building booking flows on a calendar API, prototyped from the terminal.

Written by Nick Barraclough Product Manager

Reviewed by Qasim Muhammad

VerifiedCLI 3.1.17 · Google, Outlook · last tested June 9, 2026

Why look for an Acuity Scheduling API alternative?

The Acuity Scheduling API manages an existing Acuity account: it reads and writes the appointments, clients, and availability that live inside your own Acuity business. It was never designed to power scheduling for your product's users, which is why developers embedding booking into their own apps end up shopping for an alternative.

Acuity has been part of Squarespace since 2019, and its developer API reflects that account-centric history. According to the Acuity developer docs, authentication is HTTP Basic with a user ID and API key, and every endpoint operates on one Acuity account's appointments, clients, forms, and availability. That model works when you're extending your own booking business. It breaks down when each of your users needs to connect their own Google or Outlook calendar and accept bookings inside your app, because there's no per-user calendar connection to build on.

Searches for an alternative usually mean one of two things. Some teams want a different booking product with a friendlier API. Others want to stop renting a booking product entirely and own the flow. The first group should compare Cal.com and Calendly; the second needs calendar primitives, and that path is testable from a terminal in minutes.

What are the main Acuity Scheduling API alternatives?

Three options cover most embedded-scheduling needs: Cal.com, an open-source scheduling product you can self-host and drive through its API; the Calendly API, which manages booking links and reads events booked on Calendly's hosted pages; and a calendar API like Nylas, where you build the booking flow yourself from availability and event primitives.

DimensionCal.comCalendly APICalendar API (Nylas)
What it isOpen-source scheduling productAPI over a hosted booking productRaw availability + event API
Booking UIBuilt in, embeddableCalendly-hosted pagesYou build it
Self-hostYesNoHosted API
Where booking happensYour embed or their pageCalendly's pageInside your product
Best forBooking pages fast, with source accessAutomating an existing Calendly setupScheduling woven into your own workflow

Cal.com launched in 2021 as an open-source Calendly alternative, and its API v2 is the fastest path to embedded booking pages you can also self-host. The Calendly v2 API authenticates with OAuth 2.0 or personal access tokens, but bookings still happen on Calendly-hosted pages, so the API observes bookings more than it creates them. Building on a calendar API is the one option where the form, the rules, and the data model are entirely yours.

The trade-off is honest on both sides. A product gets you live this week with someone else's booking rules; an API costs you the build but removes the per-seat pricing and the redirect to a third-party page. The next three sections walk the build path end to end with three commands, so you can judge the effort before committing.

How do I check availability without a scheduling product?

The nylas calendar availability find command searches for open meeting slots straight from a connected Google or Outlook calendar. It defaults to 30-minute slots scanned at 15-minute intervals over a 7-day window, and --json returns the slots as data your booking UI can render directly.

nylas calendar availability find \
  --participants host@example.com \
  --duration 30 \
  --interval 15 \
  --json

For a yes/no answer about one specific window, the nylas calendar availability check command reports free/busy status for any set of email addresses. It accepts natural-language times, so a quick terminal test needs zero date formatting before you wire the same call into your backend.

nylas calendar availability check \
  --emails host@example.com \
  --start "tomorrow 9am" \
  --end "tomorrow 5pm"

Both commands read live free/busy data, so a slot that shows up here reflects the host's actual calendar, including events booked outside your product. Pipe the JSON into your backend or straight into a frontend response. The full slot-to-website wiring, including timezone handling, is covered in the booking page guide.

How do I create the booking once a visitor picks a slot?

The nylas calendar events create command writes the booking to the host's real calendar and invites the visitor as a participant. The calendar provider sends the invitation email itself, so a confirmed booking blocks the slot and appears in both calendars like any hand-created event. Add --location for a meeting link and --description for agenda notes; both carry through to the invite.

nylas calendar events create \
  --title "Intro call with Sam" \
  --start "2026-06-12 14:00" \
  --end "2026-06-12 14:30" \
  --participant "visitor@example.com" \
  --json

If you omit --end, the CLI defaults the end time to 1 hour after the start. One detail matters in production: re-run the availability check for the exact chosen window right before creating the event, because another visitor may have taken the slot since your UI rendered it. That re-check pattern, plus the double-booking failure modes it prevents, is walked through in the availability booking page guide.

How do I keep bookings in sync after they change?

Webhooks keep an embedded scheduler honest. The nylas webhook create command registers your endpoint for the event.created and event.updated triggers, so a decline, reschedule, or cancellation made directly in Google Calendar or Outlook lands in your app without polling.

nylas webhook create \
  --url "https://api.example.com/calendar-hooks" \
  --triggers event.created,event.updated \
  --description "Booking sync"

Here's the polling math the TL;DR promised: checking 1,000 bookings every 5 minutes is 288,000 requests a day, and most return nothing new. One webhook registration replaces all of it. For local development, nylas webhook server --port 8080 runs a receiver on your machine so you can watch reschedule payloads arrive before you deploy anything, and nylas webhook verify checks payload signatures against your webhook secret so you only trust genuine notifications. The Nylas Scheduler docs cover the hosted booking-page option if you later want the UI managed for you.

Next steps