Cal.com is a scheduling product with public booking pages, team calendars, organization settings, API tokens, and SSO. A public page can be intentionally reachable without authentication. An organization control plane should not be. A product title match can represent either one, so the exposure review has to separate scheduling from administration.
What the measurement shows
On 2026-11-10 at 03:44:28 +08:00, title="Cal.com" returned 2,124 assets with sub_type=all, page 1, and pagesize 1. The saved search is a title observation.
The count can include public booking pages, login screens, documentation, and custom deployments. It does not prove that an organization admin or API endpoint is exposed. The asset owner and route matter more than the product name.
Public scheduling is not public administration
Cal.com organizations support team members, roles, and SSO. Owner, Admin, and Member roles have different rights. Custom roles can narrow what a person can change. A booking page may need to be public so clients can schedule a meeting. That does not justify exposing the organization's user management, billing, SSO configuration, or API token settings.
Check which routes are intended to be public and which are protected by the identity provider. Test a logged-out request to the booking page and a logged-out request to the admin path. Confirm that a team member cannot change organization-level settings unless the role allows it. Review the login flow for SAML or OIDC, the allowed redirect URLs, and the administrator list. A second identity provider or an old local login can bypass a carefully designed SSO policy if both are enabled.
API roles and scopes
Cal.com's access-control documentation describes three layers for organization and team API endpoints: membership roles, permission-based access control, and OAuth access token scopes. The endpoint may require a minimum team or organization role. The access token may also need a scope. An instance-level administrator role does not automatically grant system-wide authority through every public API endpoint. These layers are useful, but they create test cases: a token can be valid yet lack the role or scope required by a particular operation.
Create one API client or token per integration. Record its owner, scopes, organization, and the operations it performs. Rotate it when a team member leaves or an integration is replaced. Do not use a personal access token as a shared service credential. For OAuth, review the consent screen and redirect URI. A token issued to one organization should not be usable to administer another unless the design explicitly allows it.
Scheduling data and third-party integrations
Scheduling records can include names, email addresses, meeting notes, and calendar metadata. The booking page's public nature does not make all of that data public. Review the event type fields, cancellation policy, webhook payloads, and calendar connections. A webhook that forwards booking data to an internal service needs signature or source validation and a bounded retry policy. A calendar integration may receive more data than the booking page displays.
The administrative surface should be protected with strong authentication, least-privilege roles, and a separate network path where possible. Review the organization member list, custom roles, SSO enforcement, SCIM provisioning, and any impersonation feature. Remove old members and sessions. An employee who leaves may keep a personal API token even if the SSO account is disabled.
Exposure review
Map the title matches to owned domains and custom deployments. Classify each host as a booking page, user dashboard, organization admin, or API host. For each, verify the intended public route, authentication method, role model, and token inventory. Check whether a public booking page leaks internal event types or team information. Confirm that an unauthenticated request cannot reach administrative data.
The 2,124 matches are not evidence of exposed organizations. They show that Cal.com is visible enough to warrant a route-level inventory. The correct unit of analysis is the organization and the role behind the page, not the product title alone.