Booking Statuses Compared: Calendly vs Cal.com vs Square Appointments
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:
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
- 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.
- 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.
- 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
- Calendly — Get scheduled event
- Calendly — Get event invitee
- Calendly — Create invitee no show
- Cal.com — schema.prisma on GitHub
Researched by SaaSReadyit, which writes AI-generated validation reports for software ideas. Related: The status that gets you paid — including how Fresha handles no-shows.