Appointment scheduling APIs: which one should you build on?

Every few weeks someone asks a version of the same question in a dev forum: "I need to add appointment booking to my app — what API should I use?" The answers that come back are usually a list of product names with no distinction between them, and the person picks the one with the nicest docs site. Three weeks later they discover the API they chose can create a meeting link but cannot express "this service takes 90 minutes, needs one of three qualified staff, and costs £60 with a £20 deposit."

The confusion is understandable, because "appointment scheduling API" covers at least four different categories of product that share almost nothing beyond the word calendar. Choosing well is mostly about working out which category you're actually in.

I build one of these, so treat the Opencals section accordingly. I've tried to be accurate about the others, because for a lot of projects one of them is the right answer and pretending otherwise would waste your time.

The four categories, before any product names

Calendar sync. You need to read a user's real availability out of Google, Microsoft 365, iCloud and Exchange, and write events back. The hard part is OAuth across four providers, webhook reliability, recurring-event edge cases and timezone handling. Nylas and Cronofy exist because that problem is genuinely nasty and nobody wants to solve it twice.

Meeting scheduling. You need "book a call with me" inside your product — a link, a round-robin pool, a qualification form. Calendly and Cal.com are built for this and they're good at it.

Service commerce. You need to sell a service with a price attached: a 90-minute massage, a 45-minute lesson, a group class with twelve seats, a two-day equipment rental. Availability is a function of staff, location, service duration and capacity, and there's usually money involved. This is a different data model, not a harder version of meeting scheduling.

Raw provider APIs. Google Calendar API and Microsoft Graph. Free, well-documented, and they give you a calendar — not a booking system. Everything above the event object is yours to build.

Most people who search for an "appointment scheduling API" are in category two or three and don't yet know which.

Cal.com Platform

Cal.com is the open-source scheduling platform, and its Platform product is the API/embed offering for developers who want to put Cal.com's scheduling inside their own app or marketplace.

It's a real option and the docs are good. The thing to check before you commit is the price shape. Platform plans start around $299/month for the Starter tier, which includes a small number of bookings, with per-booking overage of roughly $0.99 dropping to $0.60 and $0.50 on the higher tiers. That's a sensible model if you're a funded company embedding scheduling for thousands of users. It's a lot of money if you're an agency shipping a booking site for one salon.

You can also self-host Cal.com, which changes the economics entirely and adds an operations burden. I wrote about that trade-off in more depth in open-source vs hosted booking API.

Good for: marketplaces and SaaS products embedding meeting-style scheduling at scale, teams that want the option to self-host. Watch for: meeting-scheduling data model, platform pricing floor.

Cronofy

Cronofy is a calendar API with real scheduling intelligence layered on top — availability queries across multiple participants and providers, with strong privacy controls that matter in regulated environments. It's the tool a lot of ATS and interview-scheduling products are quietly built on.

Pricing sits at the enterprise end. Public information for 2026 points to a usage-based model with a $99/month minimum and plan tiers that climb quickly from there. That's not a criticism — it's priced for the companies it serves.

Good for: B2B products where scheduling coordinates multiple humans' real calendars, interview and recruitment tooling. Watch for: it's an availability and calendar layer, not a service catalogue with prices.

Nylas

Nylas treats calendar as one of three connected surfaces alongside email and contacts. If your product needs to sync a user's inbox and their calendar, that consolidation is worth something. Calendar-only entry pricing starts low, but realistic starting points for a production product land in the hundreds per month and scale with connected accounts and call volume.

Good for: products that need email plus calendar plus contacts from one integration. Watch for: you're buying connectivity, not a booking engine.

Calendly API

Calendly's API is best understood as an extension of Calendly rather than a platform to build a product on. You can list event types, read scheduled events, subscribe to webhooks and route people to booking pages. API access comes in from the Standard plan, around $10/user/month, with the deeper capabilities on Enterprise.

Calendly is genuinely excellent at what it does. It's just that "what it does" is one person's meeting availability, and per-user pricing is awkward when your end users are businesses rather than seats you control.

Good for: automating around a Calendly account you already use. Watch for: per-user pricing, no service/price model.

Acuity Scheduling API

Acuity sits closer to service businesses than Calendly does — it understands appointment types, add-ons and packages. API access requires the Premium plan at around $49/month, with no per-user fees, which is friendlier than Calendly's shape for small projects.

The limitation is that the API is built to automate a single Acuity account. It isn't designed as multi-tenant infrastructure, so if you're an agency serving twenty clients you're managing twenty accounts and twenty keys.

Good for: automating one service business's existing Acuity setup. Watch for: single-tenant by design.

Google Calendar API and Microsoft Graph

Free, stable, thoroughly documented, and the correct answer more often than people expect — if what you need is a calendar.

What you don't get: services with prices, staff qualification rules, capacity for group sessions, buffers, deposits, cancellation policy, customer records, or payment. Every one of those is code you write and then maintain. Teams routinely underestimate the availability engine specifically. "Which slots can this business actually offer on Thursday" is not a query against a calendar; it's a computation over staff shifts, service duration, location hours, existing bookings and buffer rules.

Good for: internal tools, prototypes, anything where the calendar is the product. Watch for: you are signing up to build a booking system.

Opencals Storefront API

This is the one I built, so here's the honest framing.

Opencals is a service-commerce backend with a public Storefront API and a typed TypeScript SDK. The data model starts from services and staff rather than from calendar events: a service has a duration, a price, a set of staff who can perform it, a location, and optionally a capacity for group sessions. Availability is computed from those inputs at request time rather than stored as fixed slots. Payment, deposits, add-ons, invoices and the customer portal are part of the platform, not something you bolt on.

You keep the entire frontend. The API is what sits behind it — that's the headless approach the whole thing is designed around, and there are worked examples for Next.js if you want to see the shape of it.

Pricing is $0.99 per booking on the Elastic plan, with no separate developer tier and no monthly floor. That matters most for agencies: a client site that takes forty bookings in December costs about forty dollars, not a platform subscription. If you build booking sites for other people, that's the case we make on the agencies page.

Good for: service businesses, custom booking frontends, agency work, anything where a booking has a price and a duration. Watch for: it's not a meeting scheduler. If you want "book a 30-minute call with me," Calendly or Cal.com is simpler and I'd say so. It's also a younger platform than the incumbents — the API surface covers the booking flow well, but it isn't a decade-old ecosystem.

Side by side

Five questions that actually decide it

Where most projects go wrong

Two failure patterns come up repeatedly.

The first is choosing a meeting-scheduling API for a service business. It works in the demo, because one practitioner offering one 30-minute service looks identical in both models. It breaks the moment a second staff member appears with different hours and a different service list, or the moment a deposit needs taking.

The second is choosing a calendar API and planning to "just build the booking logic ourselves." That logic is a real system: overlapping resources, buffers, lead times, capacity, timezone-correct recurring rules, concurrency when two people click the same slot. It's a fun problem, which is exactly why it eats quarters. If booking isn't your product, buying that layer is the cheaper decision, and I say that as someone who spent two years building it.

If you're still deciding between building on an API and just embedding a widget, that comparison is here.

The short version

Work out which of the four categories you're in, then let pricing shape decide between the two or three candidates left. If a booking in your product has a price and a duration and involves a specific person or room, you want a service-commerce API and most of this list is the wrong shape. If it's "find a time to talk," you want meeting scheduling and you'll be done in a day.

If you're in the first group, the Opencals developer docs are the place to start, and the booking API guide walks through a full flow with code.