Booking API comparison
A comparison written by one of the products in it deserves suspicion, so here are the rules this page follows. Every statement about another product links to that product’s own documentation or pricing page, and says the day it was checked: prices and plans change, and a claim with no date is a claim nobody can recheck. Where another product is the better choice, the page says so first. What Bookrail does not do is listed with the same care as what it does. If something here is wrong or has gone stale, open an issue and it will be corrected.
The short answer
Section titled “The short answer”The products on this page solve two different problems that share the word “booking”.
Meetings between people and their calendars. A prospect books thirty minutes with a salesperson; a patient books a video call with a therapist; a team shares interview slots. The hard part is reading and writing Google, Microsoft and Apple calendars, finding the time when several people are free, and sending the video link. Calendly, Cal.com, Nylas and Cronofy are built for this, and they are good at it. Bookrail does not connect to any external calendar, so if this is your problem, pick one of them.
Capacity of things, inside your product. Courts, rooms, seats in a class, bikes, a chair and the stylist who works at it, sold by your own app with its own rules. The hard part is that two customers must never get the last unit, that opening hours live in a time zone with a clock change in it, that the refund terms the customer accepted stay the terms of that booking, and that the app hears about every change. That is what Bookrail is for: an API with no end-user interface of its own, capacity enforced by Postgres, and the edge cases listed with the test that proves each one.
One calendar, little traffic, nothing else. Neither: a table with a Postgres exclusion constraint is enough, and Build or buy shows it.
Bookrail, first, with its gaps
Section titled “Bookrail, first, with its gaps”What it is: booking infrastructure behind one HTTP API, with an SDK for TypeScript, a CLI and an MCP server for coding agents. Resources with a capacity, resource groups, services that need several resources at once, schedules with exceptions in the time zone of the place, holds, bookings with an idempotency key, cancellation and refund policies frozen on each booking, payments of a deposit or the full price on your own Stripe account, and signed webhooks. Apache 2.0, self-hostable, priced per booking with a Free plan.
What it does not have, on the day this page was written:
- No calendar sync. No Google, Microsoft or Apple calendar, in either direction.
- No video conferencing links, and no email or SMS to your customers.
- No booking page, widget or UI components. You build the interface; the Next.js and Supabase guides show the smallest one.
- One SDK language, TypeScript. Every other language uses the HTTP API and the OpenAPI document.
- No recurring series and no multi-day booking across a closure yet.
- Early access. A young product, with no track record of years in production. The edge cases page and the public repository are the evidence it offers instead.
Cal.com
Section titled “Cal.com”Where it is stronger. A complete scheduling product, which Cal.com says is used by over a million people, with connectors for Google, Outlook and Apple calendars, its own video conferencing, round-robin and collective team events, seated events where several attendees book one slot, payments through Stripe, and webhooks. It has compliance certifications (SOC 2, HIPAA, ISO 27001 on its Organizations plan) that Bookrail does not have. Its API v2 covers bookings, event types, slots, calendars and webhooks.
Where it differs. Its model is built around a person’s calendar and an event type. For a room, Cal.com’s own guidance is to create each space as its own account inside an Organization, which says what the model was built around: people’s calendars rather than units of capacity. Two changes in the last year matter to anybody building on it:
- The “Platform” plan, the offer aimed at developers embedding Cal.com in their product, took no new signups from 15 December 2025; existing customers keep support.
- On 14 April 2026 Cal.com moved its production codebase to closed source. The open code continues as Cal.diy, under the MIT licence, without Teams, Organizations, Insights, Workflows and SSO.
Pricing is per user: Free for one user, Teams and Organizations per user per month, Enterprise on request.
Sources, checked on 25 September 2026: API v2 introduction (Platform plan, rate limits, sections of the API), Platform FAQ, closed source announcement, Cal.diy repository, home page (users, integrations), pricing, seats, round-robin, payments, webhooks, facility scheduling.
Calendly
Section titled “Calendly”Where it is stronger. A widely used scheduling product, with calendar integrations for
Google, Outlook and Office 365 and Microsoft Teams, and plans for teams. Since October 2025
its Scheduling API creates bookings directly (POST /invitees, “no redirects, iframes, or
Calendly UI required”), and the API checks that the start time is an open slot at booking time.
If your bookings are meetings with people who keep their calendar in Google or Microsoft, it is
a strong choice with nothing to build.
Where it differs. It is built to schedule people’s time, and it is a finished product with an API rather than infrastructure: Calendly’s plans and data model come with it. The Scheduling API needs a paid plan, and webhooks need Standard or above. Pricing is per seat per month.
Sources, checked on 25 September 2026: Scheduling API guide, launch announcement, API FAQ (webhooks by plan), pricing.
Where it is stronger. Calendar and email infrastructure for developers: one API over Google, Microsoft, iCloud and Exchange calendars, an availability endpoint that finds common free time across many people, and a Scheduler with hosted pages, web and React components, covering one-on-one, collective, round-robin and group meetings. Nylas lists room resource booking on every plan, SOC 2, HIPAA and ISO 27001, and a free plan to start.
Where it differs. Its source of truth is the calendars of your users; it is the right layer when bookings must appear in, and respect, those calendars. Nothing on the pages below describes cancellation policies, deposits or refunds. Pricing is a monthly plan plus a price per connected account.
Sources, checked on 25 September 2026: pricing, Scheduler, calendar providers, availability endpoint.
Cronofy
Section titled “Cronofy”Where it is stronger. Calendar sync and scheduling for enterprise software: Google, Microsoft 365, Exchange and Apple calendars, an Availability API that finds common time for groups (including resources as participants), and Real-Time Scheduling, a hosted page on which a person picks a time and the event is written into the calendars. Six data centres, a 99.99% uptime guarantee on its plans, and a long list of certifications: ISO 27001, 27701 and 27018, SOC 2 Type 2, and a HIPAA Business Associate Agreement.
Where it differs. It is built for software that schedules people across their calendars, priced for that: plans start in the hundreds of dollars a month, by the number of synced calendar accounts. Nothing on the pages below describes cancellation policies or payments.
Sources, checked on 25 September 2026: API pricing, plans and pricing, Availability API, Real-Time Scheduling, supported calendars, compliance.
Acuity Scheduling
Section titled “Acuity Scheduling”Where it is stronger. A finished booking product for small businesses: a client-facing booking page, payments through Stripe, Square, PayPal or Venmo, video meeting links, and a HIPAA option. For a single business that wants a booking page this week and has no developer, it is the more direct answer. Its API creates appointments and validates availability as a client booking would.
Where it differs. It is an app for the business, with an API on top, not a layer to build a product on: the custom API is a feature of its Premium plan, and the plans are counted in the calendars of one business.
Sources, checked on 25 September 2026: create appointments, plans.
Timekit
Section titled “Timekit”Where it is stronger. The closest in intent: a booking API where “users, rooms, employees or assets can be resources”, with plans that include the booking and availability API and webhooks.
Where it differs. Pricing is by the resource that gets a booking in a month, and the API and webhooks start on the Professional plan. Its developer documentation could not be reached on the day this page was checked, so nothing more about the API is claimed here.
Sources, checked on 25 September 2026: pricing.
Supabase, Firebase and a table of your own
Section titled “Supabase, Firebase and a table of your own”Supabase and Firebase are the backends many of these apps already run on, and neither has a
booking primitive: they give you a database, and the booking logic is yours. On Supabase that
database is Postgres, which has exactly the right tool for the core of it, an exclusion
constraint over a time range, and Supabase supports the btree_gist extension it needs. If you
have one calendar and little concurrency, that constraint is the whole engine you need, and
Build or buy shows it. If you need more, the
Supabase guide puts Bookrail behind Edge Functions and keeps your table
as a read model.
Sources, checked on 25 September 2026:
Supabase documentation,
Supabase extensions (btree_gist),
Firebase products,
PostgreSQL, constraints on ranges.
Side by side
Section titled “Side by side”| Built for | Capacity of things | External calendars | Interface | |
|---|---|---|---|---|
| Bookrail | Bookings inside your product | Resources, groups, composite requirements | No | You build it |
| Cal.com | Meetings, teams | Seats per event; a space is an account | Yes | Hosted pages, React components, or your own |
| Calendly | Meetings | Not claimed here | Yes | Calendly’s, or your own through the Scheduling API |
| Nylas | Calendars and meetings in your product | Room resources | Yes | Hosted Scheduler, components, or your own |
| Cronofy | Calendars and meetings in enterprise software | Resources as participants | Yes | Hosted page, or your own |
| Acuity Scheduling | A small business’s booking page | Not claimed here | Yes | Acuity’s booking page, or your own through the API |
| Timekit | A booking API | Resources | Not claimed here | Not claimed here |
| A Postgres table | One calendar | What you write | No | You build it |
Every cell about another product comes from the sources under its section, checked on 25 September 2026. The columns are the questions this page was asked to answer, not a scorecard: a “No” is only a problem if you need that column.