# Appointment scheduling APIs: which one should you build on? > Cal.com, Cronofy, Nylas, Calendly, Acuity and Opencals scheduling APIs compared on vendor pricing checked October 2026, and what each is built for. URL: https://opencals.com/blog/appointment-scheduling-api Author: Stanislav Tyshchenko Published: 2026-08-29 Updated: 2026-10-12 Categories: comparison, engineering 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. > **Key takeaway** > > There are four kinds of scheduling API and they are not interchangeable. Calendar-sync APIs (Nylas, Cronofy) read and write events across providers. Meeting-scheduling APIs (Calendly, Cal.com) automate 1:1 and round-robin bookings. Service-commerce APIs (Opencals) model services, staff, duration, capacity and payment. Raw provider APIs (Google, Microsoft) give you primitives and nothing else. Pick the category first, the vendor second. ## 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](https://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](https://cal.com/platform) routes API keys through "Talk to sales". The last published Platform tiers, as recorded by [third-party trackers](https://zeeg.me/en/blog/post/cal-com-pricing), 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](https://opencals.com/blog/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](https://www.cronofy.com/pricing) (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](https://www.nylas.com/pricing/) (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](https://calendly.com/pricing) (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](https://acuityscheduling.com/signup.php), 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](https://opencals.com/blog/booking-api) and a typed [TypeScript SDK](https://opencals.com/blog/booking-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](https://opencals.com/blog/headless-booking-system) the whole thing is designed around, and there are [worked examples for Next.js](https://opencals.com/blog/add-booking-to-nextjs-app) if you want to see the shape of it. There are two plans and no separate developer tier ([pricing](https://opencals.com/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](https://opencals.com/agencies). 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 | API | Category | Entry pricing (2026) | Models price + duration? | Best fit | | ----------------------- | --------------------------- | -------------------------------------------------------- | ------------------------ | ---------------------------------------------- | | Cal.com Platform | Meeting scheduling | Talk to sales (last published: $299/mo for 500 bookings) | Partly | Marketplaces, embedded scheduling at scale | | Cronofy | Calendar + availability | $819/mo billed annually (500 synced accounts) | No | Interview & multi-party scheduling | | Nylas | Calendar + email + contacts | $15/mo for 10 calendar accounts, then $1.70 each | No | Products needing inbox + calendar | | Calendly API | Meeting scheduling | $10/seat/mo (Standard) | No | Automating an existing Calendly account | | Acuity API | Appointments | $49/mo annual, $61 monthly (Premium) | Yes | One service business, single tenant | | Google Calendar API | Raw calendar | Free | No | Internal tools, prototypes | | Opencals Storefront API | Service commerce | $0.99/booking, or $14.98/mo for 300 | Yes | Service businesses, custom frontends, agencies | 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 1. **Does a booking have a price?**: If yes, you're in service commerce and calendar-sync APIs will not get you there. If no, meeting-scheduling APIs are simpler and cheaper. 2. **Who computes availability?**: Ask whether the API returns bookable slots given a service and a date, or whether it returns raw calendar events you must reason over. That single difference is often several weeks of work. 3. **How many tenants?**: One business, or many? Single-tenant APIs like Acuity's are fine for one client and painful for twenty. Agencies should filter hard on this. 4. **What shape is the bill?**: Per user, per month, per connected account, or per booking. Model your worst month, not your best one — a $299/month floor against a client doing thirty bookings is the number that kills projects. 5. **What happens after the booking?**: Reschedules, cancellations, refunds, no-show fees, reminders, invoices. Some APIs stop at 'event created' and leave the entire post-booking lifecycle to you. > **A cheap sanity check** > > Before you commit, write the availability call you'd need on day one — the real one, with your actual service durations and staff rules — and see whether the API can express it in a single request. If it takes three calls and client-side merging, you've found your integration cost early rather than late. ## 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](https://opencals.com/blog/embed-booking-system). ## Frequently asked questions ### What is an appointment scheduling API? An API that lets your application create and manage appointments programmatically — checking availability, creating bookings, handling reschedules and cancellations — instead of sending users to a third-party booking page. The term covers several different product categories: calendar-sync APIs, meeting-scheduling APIs, and service-commerce APIs that also model service duration, staff and price. ### Is there a free appointment scheduling API? Google Calendar API and Microsoft Graph are free and give you calendar read/write, but not a booking system — no services, prices, staff rules or availability computation. Cal.com can be self-hosted at no licence cost, though you take on hosting and maintenance. Most hosted booking APIs have either a monthly floor or per-booking pricing; free tiers that exist are usually capped low enough to be development-only. ### What is the difference between a calendar API and a booking API? A calendar API reads and writes events on someone's calendar. A booking API answers the harder question of what can be booked in the first place — given a service duration, which staff are qualified and working, what the location hours are, what buffers apply and what's already booked. Calendar APIs give you primitives; booking APIs give you bookable slots. ### Which scheduling API is best for a multi-tenant SaaS? Check whether the API is designed for one account or many before anything else. Acuity's API automates a single business account, so serving twenty clients means twenty accounts. Cal.com Platform and Opencals are both designed for multi-tenant use, but with very different pricing shapes: a platform subscription versus per-booking cost. Model both against your expected volume per tenant. ### Can I use a scheduling API to take payments? Only some of them. Calendar-sync and meeting-scheduling APIs generally stop at creating the event, leaving payment to you and Stripe. Service-commerce APIs like Opencals treat payment as part of the booking flow, including deposits, add-ons and post-booking invoicing, because a booking with a price attached is incomplete without it. ### How much does an appointment scheduling API cost in 2026? Checked against vendor pricing pages on 12 October 2026: Google Calendar API and Microsoft Graph are free. Calendly is $10 per seat a month on Standard. Nylas starts at $15 a month for 10 calendar accounts. Acuity's API needs Premium at $49 a month billed annually. Cronofy's API plans start at $819 a month billed annually. Cal.com no longer publishes Platform pricing; the last published tier was $299 a month for 500 bookings. Opencals is $0.99 per booking, or $14.98 a month including 300 bookings. Model your quietest month, not your busiest. ### Should I build my own booking system instead? If booking is your product, yes — you'll need control over the availability engine anyway. If booking is a feature of something else, the availability engine is usually a much larger project than it looks, because the difficulty is in resource contention, buffers, capacity and timezone-correct recurrence rather than in storing appointments. 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](https://opencals.com/developers) are the place to start, and the [booking API guide](https://opencals.com/blog/booking-api) walks through a full flow with code.