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 price is harder to pin down than it used to be. When I checked on 12 October 2026, cal.com/platform/pricing redirected to the ordinary Cal.com pricing page (Teams at $12 per user a month, Organizations at $28, both on yearly billing), and the developer page routes API keys through "Talk to sales". The last published Platform tiers, as recorded by third-party trackers, were a free Starter with 25 bookings, Essentials at $299 a month with 500 bookings and $0.60 per extra booking, and Scale at $2,499. Treat those as a guide to the shape rather than a quote: budget for a monthly platform fee plus overage, and ask sales for the real number. 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. On Cronofy's pricing page (checked 12 October 2026), the calendar API is sold as OEM plans: Emerging is $819 a month billed annually and includes up to 500 synced accounts, then $1.39 per extra account; Growth is $2,399 a month for up to 3,000. The $99 monthly minimum you'll see quoted around the web applies to Cronofy's standalone Meeting Agents product, not to building on the API. That's not a criticism of Cronofy. 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. Entry pricing is lower than it looks from the outside. On Nylas's pricing page (checked 12 October 2026), Essentials is $15 a month with 10 calendar-only connected accounts and $1.70 for each one after that; Pro starts at $49 with 35. The bill scales with connected accounts, so model it per end user: a product with 400 users connecting calendars is a very different invoice from the one on the pricing page.

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. On Calendly's pricing page (checked 12 October 2026), Standard is $10 per seat a month and Teams $16, and custom webhooks start at Standard, with the Data Deletion API and admin controls on Enterprise, which starts at $15k a year.

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 is on the Premium plan: $49 a month billed annually or $61 month to month (Acuity pricing, checked 12 October 2026), 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, the one I built

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.

There are two plans and no separate developer tier (pricing, checked 12 October 2026). Elastic is $0.99 per booking with no monthly fee. The monthly plan is $14.98 including 300 bookings, then $0.20 each. The full API is on both. That matters most for agencies: a client site that takes forty bookings in December costs about forty dollars on Elastic, and a busy one moves to the monthly plan once it passes roughly 16 bookings a month. If you build booking sites for other people, that's the case we make on the agencies page. You can build against a free Dev Store, but it runs in test mode and can't take real payments until it's switched to a live store.

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

Every price in this table was checked on the vendor's own pricing page on 12 October 2026, except Cal.com Platform, which no longer publishes one.

What changed since I first wrote this

The first version of this page, in late August, quoted third-party roundups for most of these prices. Rechecking against the vendors themselves moved two numbers a lot. Cronofy's "$99 minimum" turned out to belong to a different product, and the API itself starts at $819 a month. Cal.com stopped publishing Platform prices at all. Both changes push in the same direction: the calendar-infrastructure end of this market is getting more enterprise and less self-serve, and if you're small, the self-serve options (Nylas Essentials, Acuity Premium, per-booking pricing) are where you'll actually be able to start this week.

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.

My recommendation, if a booking in your product has a price, a duration and a specific person or room attached: skip the calendar-infrastructure vendors entirely, because you'd be paying enterprise prices to build the part they don't do. If it's "find a time to talk", use Calendly or Cal.com 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.