512002aaef
* refactor: replace FeaturesRepository with DI-based feature repositories Migrate from the legacy FeaturesRepository pattern to separate DI-based repositories: - Add checkIfFeatureIsEnabledGlobally to IFeatureRepository - Add getTeamsWithFeatureEnabled to ITeamFeatureRepository - Update CalendarSubscriptionService to use featureRepository, teamFeatureRepository, and userFeatureRepository - Update SelectedCalendarRepository.findNextSubscriptionBatch to filter by teamIds instead of featureIds - Update OnboardingPathService to use DI via getFeatureRepository() - Remove prisma parameter from OnboardingPathService callsites Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * test: update tests to use new DI-based feature repositories Update CalendarSubscriptionService and SelectedCalendarRepository tests to use the new separate repository interfaces: - featureRepository for global feature checks - teamFeatureRepository for team-level feature checks - userFeatureRepository for user-level feature checks Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * fix: update API routes to use DI-based feature repositories Update cron and webhook routes to use the new separate repository interfaces instead of the combined FeaturesRepository. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * fix: remove prisma arg from getGettingStartedPathWithParams call The OnboardingPathService method no longer requires a prisma argument as it now uses DI containers internally. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * test: update route tests to expect new DI-based feature repositories Update service instantiation tests to expect featureRepository, teamFeatureRepository, and userFeatureRepository instead of the old featuresRepository. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * fix: optimize global feature check and add guard in checkForNewSubscriptions - Use targeted select for only `enabled` field in checkIfFeatureIsEnabledGlobally - Add global feature flag guard in checkForNewSubscriptions to avoid unnecessary DB queries and API calls when the cache feature is globally disabled Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * remove redundant comment --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Enterprise Edition
Welcome to the Enterprise Edition ("/ee") of Cal.com.
The /ee subfolder is the place for all the Enterprise Edition features from our hosted plan and enterprise-grade features for Enterprise such as SSO, SAML, OIDC, SCIM, SIEM and much more or Platform plan to build a marketplace.
❗ WARNING: This repository is copyrighted (unlike our main repo). You are not allowed to use this code to host your own version of app.cal.com without obtaining a proper license first❗
Setting up Stripe
- Create a stripe account or use an existing one. For testing, you should use all stripe dashboard functions with the Test-Mode toggle in the top right activated.
- Open Stripe ApiKeys save the token starting with
pk_...toNEXT_PUBLIC_STRIPE_PUBLIC_KEYandsk_...toSTRIPE_PRIVATE_KEYin the .env file. - Open Stripe Connect Settings and activate OAuth for Standard Accounts
- Add
<CALENDSO URL>/api/integrations/stripepayment/callbackas redirect URL. - Copy your client*id (
ca*...) toSTRIPE_CLIENT_IDin the .env file. - Open Stripe Webhooks and add
<CALENDSO URL>/api/integrations/stripepayment/webhookas webhook for connected applications. - Select all
payment_intentevents for the webhook. - Copy the webhook secret (
whsec_...) toSTRIPE_WEBHOOK_SECRETin the .env file.
Setting up SAML login
- Set SAML_DATABASE_URL to a postgres database. Please use a different database than the main Cal instance since the migrations are separate for this database. For example
postgresql://postgres:@localhost:5450/cal-saml - Set SAML_ADMINS to a comma separated list of admin emails from where the SAML metadata can be uploaded and configured.
- Create a SAML application with your Identity Provider (IdP) using the instructions here - SAML Setup
- Remember to configure access to the IdP SAML app for all your users (who need access to Cal).
- You will need the XML metadata from your IdP later, so keep it accessible.
- Log in to one of the admin accounts configured in SAML_ADMINS and then navigate to Settings -> Security.
- You should see a SAML configuration section, copy and paste the XML metadata from step 5 and click on Save.
- Your provisioned users can now log into Cal using SAML.