---
title: "Booking Statuses Compared: Calendly vs Cal.com vs Square Appointments"
short_title: "Booking Statuses: Calendly vs Cal.com vs Square"
description: "Calendly has 2 booking statuses, Cal.com 5, Square 6. Where each stores who cancelled and whether the client showed up — read from their APIs and source code."
date: 2026-09-24
products: Calendly=https://calendly.com; Cal.com=https://cal.com; Square Appointments=https://squareup.com/appointments
faq: What statuses can a Calendly event have?=A Calendly scheduled event and each invitee are either active or canceled. Who cancelled is stored as canceler_type (host or invitee), and a no-show is a separate record attached to the invitee. || What are Square Appointments booking statuses?=PENDING, CANCELLED_BY_CUSTOMER, CANCELLED_BY_SELLER, DECLINED, ACCEPTED and NO_SHOW. || What are Cal.com booking statuses?=Cal.com's source code defines CANCELLED, ACCEPTED, REJECTED, PENDING and AWAITING_HOST, with ACCEPTED as the default. No-shows are stored as boolean flags, noShow on each attendee and noShowHost on the booking.
---

# Booking Statuses Compared: Calendly vs Cal.com vs Square Appointments

<p class="meta">Researched and verified against each product's API documentation or source code on 2026-09-24.</p>

:::tldr
**Short answer:** Calendly bookings are `active` or `canceled`. Cal.com's open-source schema defines five statuses (`ACCEPTED`, `PENDING`, `REJECTED`, `CANCELLED`, `AWAITING_HOST`). Square Appointments has six, and is the only one where a **no-show** and **who cancelled** are part of the status itself. The others store those facts in separate fields.
:::

## Two questions every booking tool must answer

A booking product has to record two facts that a calendar never cares about: **who cancelled**, and **did the client turn up**. Both drive money — cancellation fees, deposits, no-show charges — and the three products store them in three different places.

| | Calendly | Cal.com | Square Appointments |
|---|---|---|---|
| Statuses | `active`, `canceled` | `ACCEPTED`, `PENDING`, `REJECTED`, `CANCELLED`, `AWAITING_HOST` | `PENDING`, `ACCEPTED`, `DECLINED`, `CANCELLED_BY_CUSTOMER`, `CANCELLED_BY_SELLER`, `NO_SHOW` |
| Who cancelled | `canceler_type` field: `host` or `invitee` | Not in the status | **In the status** |
| No-show | A separate no-show record on the invitee | Boolean flags: `noShow`, `noShowHost` | **A status** |
| Approval step | No status for it | `PENDING` / `REJECTED` | `PENDING` / `DECLINED` |

## Square Appointments: everything in the status

Square's `BookingStatus` enum has six values, and its descriptions are precise:

- `PENDING` — "An unaccepted booking. It is visible to both sellers and customers."
- `ACCEPTED` — "An accepted booking agreed to or accepted by the seller."
- `DECLINED` — "It had once been pending, but was then declined by the seller."
- `CANCELLED_BY_CUSTOMER` — "A customer-cancelled booking."
- `CANCELLED_BY_SELLER` — "A seller-cancelled booking."
- `NO_SHOW` — "The booking was accepted at one time, but have now been marked as a no-show by the seller because the client either missed the booking or cancelled it without enough notice."

That last definition is worth reading twice. In Square, a **late cancellation is a no-show**. The status represents the business consequence — the slot was lost — rather than what literally happened.

## Calendly: two statuses, facts attached

Calendly keeps the status minimal. A scheduled event's status "Indicates if the event is "active" or "canceled"," and each invitee has the same two values.

Everything else is attached rather than encoded. A cancellation carries `canceler_type`, whose allowed values are `host` and `invitee`, plus the canceller's name and reason. A no-show is its own object created through a dedicated endpoint (`POST /invitee_no_shows`) and linked from the invitee's `no_show` field. Rescheduling is tracked with a `rescheduled` boolean and a link to the old and new invitee records.

The result: an invitee who didn't turn up is still `active`. If you are pulling Calendly data into reports, filtering on status alone will count no-shows as attended.

## Cal.com: five statuses in open source

Because Cal.com is open source, its statuses can be read straight from its database schema:

```prisma
enum BookingStatus {
  CANCELLED     @map("cancelled")
  ACCEPTED      @map("accepted")
  REJECTED      @map("rejected")
  PENDING       @map("pending")
  AWAITING_HOST @map("awaiting_host")
}
```

A booking's `status` defaults to `ACCEPTED`. Alongside the status, a booking stores `cancellationReason`, `rejectionReason` and a `rescheduled` flag, and event types have a `requiresConfirmation` setting — the case `PENDING` and `REJECTED` cover.

No-shows are booleans, not statuses, and there are two: `noShow` on each **attendee** and `noShowHost` on the **booking**. Cal.com is the only one of the three that records the host failing to turn up.

## Which design to copy

1. **Put the fact in the status only if it changes what happens next.** Square does, because a no-show triggers a fee. Calendly doesn't, because its job ends at scheduling.
2. **Record who cancelled somewhere.** Every cancellation policy — refund the customer or charge them — depends on it. Square encodes it in the status; Calendly in a field. Cal.com's status enum doesn't carry it.
3. **Decide whether a late cancellation is a cancellation or a no-show.** Square has decided. Your users will ask.

## Method and limits

Square's values are from its API reference for the `BookingStatus` enum; Calendly's from its API reference for scheduled events and invitees (via its published Markdown docs); Cal.com's from the `schema.prisma` file in its public GitHub repository, main branch. All read on 2026-09-24. Cal.com's schema doesn't document what `AWAITING_HOST` is used for, so we don't describe it. We have no affiliation with any of the three.

## Sources

- Square — [BookingStatus enum](https://developer.squareup.com/reference/square/enums/BookingStatus)
- Calendly — [Get scheduled event](https://developer.calendly.com/api-docs/calendly-api/scheduled-events/get-scheduled-event)
- Calendly — [Get event invitee](https://developer.calendly.com/api-docs/calendly-api/scheduled-events/get-event-invitee)
- Calendly — [Create invitee no show](https://developer.calendly.com/api-docs/calendly-api/scheduled-events/create-invitee-no-show)
- Cal.com — [schema.prisma on GitHub](https://github.com/calcom/cal.com/blob/main/packages/prisma/schema.prisma)

---

*Researched by [SaaSReadyit](https://saasreadyit.com), which writes AI-generated validation reports for software ideas. Related: [The status that gets you paid](https://saasreadyit.com/blog/the-status-that-gets-you-paid-invoice-ninja-tutorcruncher-fresha.html) — including how Fresha handles no-shows.*