features

Active contributors: Romit, Hariom, Pedro, Eunjae, Joe

Purpose

packages/features is where Cal.diy's business logic lives. Everything that is "what the product does" — booking, scheduling, calendars, slots, schedules, auth, webhooks, notifications, OOO, no-show handling, embed SSR, and so on — has a directory under here. The web app and API v2 both depend on it; UI components in the directory are consumed by apps/web.

There are 72 subdirectories at the time of writing. Most follow the same repositories/ + services/ + di/ + lib/ + components/ shape.

Directory layout

A truncated but representative listing (packages/features/):

features/
├── apps/                       # Server-side helpers for installing/managing app integrations
├── auth/                       # NextAuth options, custom adapter, password helpers
├── availability/               # Availability slot logic
├── blocklist/                  # Block lists for emails / domains
├── booking-audit/              # Audit logging for bookings
├── bookingReference/           # Third-party booking IDs
├── bookingReport/              # Booking analytics / export
├── bookings/                   # The booking pipeline (largest module)
├── bot-detection/              # Risk scoring on signup / booking
├── busyTimes/                  # Calendar busy-time aggregation
├── cache/                      # Domain caches
├── calendar-subscription/      # Calendar push notification subscriptions
├── calendars/                  # Calendar federation (read/write across providers)
├── credentials/                # Encrypted third-party credentials
├── credits/                    # Usage credits accounting
├── crmManager/                 # CRM dispatch
├── data-table/                 # Reusable server-side table primitives
├── di/                         # Tiny DI container helpers
├── embed/                      # SSR helpers for embeds
├── eventTypeTranslation/       # i18n for custom event-type strings
├── eventtypes/                 # The EventType domain
├── feature-opt-in/             # Per-event-type feature opt-in
├── filters/                    # UI filter primitives
├── flags/                      # Feature flags
├── form-builder/               # Custom booking-question builder
├── handleMarkNoShow.ts         # Top-level helper for marking no-show
├── hashedLink/                 # Private booking links
├── holidays/                   # Holiday calendars
├── host/                       # Host (team event-type member) logic
├── membership/                 # Team memberships
├── noShow/                     # No-show flagging
├── notifications/              # In-app + push notifications
├── oauth/                      # OAuth helpers (Cal.com as an OAuth provider)
├── onboarding/                 # First-time-setup flow
├── ooo/                        # Out-of-office
├── platform-oauth-client/      # Platform tenant OAuth clients
├── profile/                    # User profile aggregate
├── redis/                      # Redis client wrappers
├── schedules/                  # Schedule CRUD + queries
├── selectedCalendar/           # SelectedCalendar (read-from list)
├── selectedSlots/              # Pending slot reservations during booking
├── settings/                   # User / team settings
├── slots/                      # Slot generation + reservation
├── tasker/                     # Deferred-task queue
├── timezone/                   # Timezone helpers + UI
├── translation/                # Runtime translation helpers
├── travelSchedule/             # Travel mode for schedules
├── trigger.config.ts           # Trigger.dev jobs registration
├── troubleshooter/             # Availability troubleshooter
├── url-shortener/              # Short URL generation
├── users/                      # User domain
├── video-call-guest/           # Public guest links to video calls
├── watchlist/                  # Email/domain risk watchlists
└── webhooks/                   # Outbound webhooks

Conventional shape

Inside any non-trivial domain you will see the same files:

<domain>/
├── repositories/
│   ├── <Domain>Repository.ts             # Prisma queries (uses `select`, never `include`)
│   └── <Domain>Repository.interface.ts   # Interface for DI
├── services/                             # Or service/ — business logic
│   └── <Action><Domain>Service.ts
├── di/                                   # Wires concrete impls behind interfaces
├── lib/                                  # Domain helpers + types
├── components/                           # React components for the dashboard
└── hooks/                                # React Query / SWR hooks

This is the convention AGENTS.md codifies. tRPC and REST layers stay thin and call services. Services own transactions and orchestration.

Highlighted domains

For full pages, see the features lens. The most important domains are:

• bookings — the booking pipeline, including handleNewBooking, handleCancelBooking, handleSeats, handleConfirmation, handleMarkNoShow. The single largest module by file count and the most-changed file in the project (RegularBookingService.ts).
• eventtypes — the EventType domain. Owns the canonical Prisma model and most of the editor UI.
• calendars — calendar federation across providers; defines the Calendar interface and orchestrates app-store calendar adapters.
• slots — slot generation; takes event-type rules, schedules, and busy times and produces candidate booking times.
• schedules — CRUD for Schedule rows and the editor UI.
• auth — NextAuth options, custom Prisma adapter, password helpers, OAuth providers.
• flags — feature flags backed by Postgres.
• tasker — in-process deferred-job queue using a Postgres-backed Task table.
• app-store apps in features/apps — server-side helpers for installing / uninstalling integrations.

Cross-cutting infrastructure

A few directories under features/ are not domains but supporting infrastructure:

• features/di/ — a tiny DI container shared by every domain's di/ directory
• features/data-table/ — server-side filtering / sorting / pagination primitives reused by every list view
• features/redis/ — Redis client wrappers used by caches
• features/trigger.config.ts — registers all Trigger.dev jobs in one place
• features/translation/ and features/eventTypeTranslation/ — runtime translation helpers

How a feature plugs in

graph TD
    PageOrController[apps/web page or apps/api/v2 controller]
    TRPCHandler[packages/trpc handler] --> Service
    PageOrController --> Service[features/<domain>/services/...Service]
    Service --> Repo[features/<domain>/repositories/...Repository]
    Repo --> Prisma[(PostgreSQL)]
    Service --> ThirdParty[App-store adapters / external APIs]
    Service --> Tasker[features/tasker queue]
    Service --> Webhooks[features/webhooks]
    Service --> Emails[packages/emails]

Entry points for modification

• Adding a domain: create packages/features/<domain>/ with repositories/, services/, di/, lib/, and (if the dashboard needs UI) components/. Add a tRPC router under packages/trpc/server/routers/ and/or a NestJS module under apps/api/v2/src/modules/.
• Changing the booking pipeline: packages/features/bookings/lib/handleNewBooking/ is the main entry point; the orchestrator is RegularBookingService.ts. See features/bookings.
• Adding a tRPC router for an existing domain: add files alongside packages/trpc/server/routers/<group>/<action>.handler.ts and register them in the group's _router.tsx.

Related pages

• Features lens — focused domain pages (bookings, eventtypes, calendars, slots, ...)
• Primitives — the shared models the feature modules orbit (EventType, Booking, User, Schedule, Credential)
• trpc — how routers consume features