cal.com architecture,
read from the code.
365,422 lines of source, 6,222 parts described, 10 areas and 18 customer paths. Scheduling infrastructure. Every line on this page comes from the model — open it and check any of them.
What the model holds.
The 10 heaviest areas of 10.
| Area | Screens | Actions | API | Records | What it covers |
|---|---|---|---|---|---|
| features | 106 | 1,377 | 0 | 23 | The product core: booking creation, rescheduling, cancellation and confirmation, availability and slots, calendar sync and cache, webhooks, tasker… |
| api | 0 | 1,038 | 175 | 2 | API v2 (NestJS): the platform REST surface — versioned bookings, slots, schedules, event types, calendars and OAuth clients with their managed users… |
| web | 695 | 155 | 84 | 1 | The Next.js web application: public booking pages, the signed-in shell, bookings/event-types/availability screens, cron endpoints and the app-router… |
| app-store | 74 | 653 | 48 | 45 | The app store: calendar, video, CRM, payment and analytics integrations, each with its OAuth install flow, credential keys, event-type app metadata… |
| lib | 29 | 389 | 0 | 7 | Shared library code: date and time helpers, string and URL utilities, permission and constant definitions used across the server and the web app. |
| trpc | 3 | 223 | 156 | 0 | The tRPC viewer API: authenticated routers and handlers behind the web app — bookings, event types, availability, apps, calendars, out-of-office and… |
| platform | 138 | 61 | 4 | 86 | Platform atoms and types: the embeddable React components (booker, availability, event types) and the shared DTO/validation types the API v2 and… |
| Shared & root | 79 | 99 | 0 | 109 | Everything not owned by another package: the Prisma schema and its entities, embed core, seed scripts and root-level configuration. |
| emails | 71 | 100 | 0 | 0 | Transactional email and SMS templates plus the services that render and send booking, auth, team and billing notifications. |
| ui | 111 | 6 | 0 | 0 | The design system: buttons, forms, dialogs, tables and layout primitives shared by the web app and the platform atoms. |
What a person walks through, step by step.
18 paths are described in the model; the longest 12 are here, with how many areas each one crosses.
End-to-end public booking: the booker page loads the event type and its slots, the visitor submits the booking form, the booking service validates limits and hosts,…
Cancellation: the request is validated and rate-limited, the booking (or the remaining recurring instances, or one seat) is marked CANCELLED, payments are refunded or a…
Paid bookings: the booking service creates a payment through the installed payment app, the booker is sent to the payment page, and the provider's webhook drives the…
The pending-request path: the booking is stored PENDING, the host is notified, and the host's confirm/reject decision either creates the calendar event and confirmation…
Calendar connection: the app store starts the provider OAuth flow, the callback stores the credential, the connected calendars are listed and defaulted, and the user…
Webhook fan-out: subscribers matching the trigger, event type, team, organization or OAuth client are looked up, each payload is signed and either POSTed immediately or…
Calendar cache and sync: a cron subscribes selected calendars to provider push channels, fetched events are folded into the calendar cache, cached busy times answer…
No-show handling: delayed tasks inspect the Cal Video session after the start time, hosts can mark attendees or themselves as no-show, the flags are written to the…
Recording delivery: the Daily webhook is verified and matched to the booking through its video reference, the booking is marked recorded, and RECORDING_READY /…
Moving a booking to a new time: reschedule restrictions are checked, the old booking is cancelled in favour of a new one, the calendar and video events are updated in…
Account creation: the signup endpoint validates the username, email and any team-invite token, refuses watchlisted emails, sends the verification mail, and the first…
Event-type setup: a new event type is created from the list page, then the editor tabs write duration, locations, booking fields and limits, hosts, private links and app…
What the product enforces on its own.
9 rules are described; each one watches a record and changes something else when it moves.
Reporting a booking cancels the upcoming instances, and blocking that report adds the booker's email or domain to the blocklist that later refuses their bookings and…
Every booking action that changes state is queued as an audit task and consumed into a BookingAudit row with the resolved actor, so the booking's history can be replayed.
Selected calendars that are due for a subscription get a provider watch channel, and every push or poll folds the fetched events into the cache that answers busy-time…
Cancelling a booking removes its integration events and every future job attached to it — scheduled webhook triggers and delayed no-show tasks — before the cancellation…
Confirming a pending booking is what actually creates the calendar entry, the video room and the CRM record, then sends the scheduled-meeting notifications.
A synced calendar event that disappears or is cancelled on the provider side cancels the matching Cal.com booking, but only when the calendar owner is the organizer.
Marking an attendee or the host as a no-show updates the booking, notifies webhook subscribers and forwards the no-show to every CRM app configured for it.
An out-of-office period is expanded into blocked working days for the absent user, removing those slots from the booker and notifying the colleague who covers the…
The states records move through.
Booking · features
Booking status
Pending → Awaiting host → Accepted → Rejected → Cancelled
5 states · 6 transitions
Payment · app-store
Booking payment state
Awaiting payment → Held → Paid → Refunded
4 states · 4 transitions
BookingReport · features
Booking report moderation status
Pending → Dismissed → Blocked
3 states · 2 transitions
Membership · features
Team membership acceptance
Invited → Accepted
2 states · 1 transitions
Answers nobody wrote down.
Computed from the model’s own connections, with the count behind each one.
How much of this product is built but unused?
74% of this product's API surface is dark: built and paid for, but part of no described customer path and consumed by no screen.
344 OF 467 ENDPOINTS · READ FROM 18 CUSTOMER PATHS DESCRIBED SO FAR
Where is it riskiest to make a change?
The riskiest place to change is “platform”: more of the product depends on platform-libraries than on anything else.
138 INBOUND DEPENDENCIES · COMPUTED FROM THE REACH GRAPH, NOT ESTIMATED
Where did the engineering effort actually go?
The deepest engineering investment is “features” — 25% of the product's mass. “ui” is compact and self-contained: the cheapest place to change.
1533 VS 118 OBJECTS · CHANGE-COST RATING = SIZE × CROSS-DOMAIN COUPLING
Which customer experience breaks first?
The most fragile customer experience is “Collect payment for a booking”: it crosses 4 domains in 11 steps — the first place integration breaks.
INTEGRATION-TEST PRIORITY №1 · DOMAINS COUNTED PER PATH STEP
Does the product lean on any one part?
One subsystem — Event Types 2024-06-14 Booking Inputs — alone carries 17 core objects. The product leans on it.
CONCENTRATION RISK · COUNTED FROM OWNERSHIP LINKS
Ask the model your own question →How these answers were scored →
About this model.
GitMir read the public repository and established what the product does: its areas, screens, actions, API routes, records, customer paths, status flows and rules, with every statement traceable to the source it came from. Nothing on this page is written by hand; it is the published model, as of 2026-09-03.
This page is a snapshot of the published model. On a connected repository the model is updated as commits land, so people and AI agents work from the product as it is now rather than as it was when somebody last wrote it down.
Yes — connect a repository and GitMir builds the same thing for it: features, rules, customer paths and how they connect, available to people on the screen and to coding agents over MCP.