Cal.com’s Platform API supports OAuth 2.0 for secure third-party application authentication. This allows your application to access Cal.com data on behalf of users with their explicit permission.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/calcom/cal.com/llms.txt
Use this file to discover all available pages before exploring further.
OAuth 2.0 Overview
OAuth 2.0 provides:- Secure delegated access without sharing passwords
- Scope-based permissions to limit what your app can access
- Token-based authentication with automatic expiration
- User consent flow for transparency
OAuth Client Setup
Creating an OAuth Client
- Log in to your Cal.com account
- Navigate to Settings > Security > OAuth Clients
- Click Create New OAuth Client
- Configure your client:
- Name: Your application name
- Redirect URIs: Allowed callback URLs (comma-separated)
- Scopes: Required permissions
Client Types
Cal.com supports two OAuth client types:Confidential Clients
Server-side apps that can securely store secrets
Public Clients
Browser-based or mobile apps using PKCE
OAuth Flows
Authorization Code Flow (Confidential Clients)
Best for server-side applications with a backend.Authorization Code with PKCE (Public Clients)
Best for single-page apps, mobile apps, or applications without a backend.Authorization Endpoint
Step 1: Redirect User to Authorization
Endpoint:GET /v2/auth/oauth2/authorize
Parameters:
| Parameter | Required | Description |
|---|---|---|
client_id | Yes | Your OAuth client ID |
redirect_uri | Yes | Must match registered URI |
response_type | Yes | Always code |
scope | Yes | Space-separated list of scopes |
state | Recommended | CSRF protection token |
code_challenge | PKCE only | SHA-256 hash of code verifier |
code_challenge_method | PKCE only | Always S256 |
Step 2: User Authorization
The user will see a consent screen showing:- Your application name
- Requested permissions (scopes)
- Option to approve or deny access
Step 3: Receive Authorization Code
After the user approves, Cal.com redirects to yourredirect_uri with:
Token Endpoint
Exchange Authorization Code for Tokens
Endpoint:POST /v2/auth/oauth2/token
Content-Type: application/x-www-form-urlencoded or application/json
For Confidential Clients
For Public Clients (PKCE)
Refreshing Access Tokens
Access tokens expire after 1 hour. Use the refresh token to get a new access token without requiring user interaction. Endpoint:POST /v2/auth/oauth2/token
For Confidential Clients
For Public Clients
Refresh tokens are single-use. Each refresh returns a new access token AND a new refresh token.
Using Access Tokens
Include the access token in theAuthorization header:
OAuth Scopes
Scopes define what your application can access:Booking Scopes
| Scope | Description |
|---|---|
READ_BOOKING | Read booking information |
WRITE_BOOKING | Create and update bookings |
Profile Scopes
| Scope | Description |
|---|---|
READ_PROFILE | Read user profile information |
WRITE_PROFILE | Update user profile |
Event Type Scopes
| Scope | Description |
|---|---|
READ_EVENT_TYPE | Read event type information |
WRITE_EVENT_TYPE | Create and update event types |
Availability Scopes
| Scope | Description |
|---|---|
READ_AVAILABILITY | Read availability schedules |
WRITE_AVAILABILITY | Update availability schedules |
Webhook Scopes
| Scope | Description |
|---|---|
READ_WEBHOOK | Read webhook configurations |
WRITE_WEBHOOK | Create and update webhooks |
Team Scopes
| Scope | Description |
|---|---|
READ_TEAM | Read team information |
WRITE_TEAM | Manage team settings |
PKCE Implementation
PKCE (Proof Key for Code Exchange) adds security for public clients.Generating Code Verifier and Challenge
Client Information
Retrieve OAuth client details: Endpoint:GET /v2/auth/oauth2/clients/:clientId
Request:
Error Responses
OAuth Errors
| Error Code | Description |
|---|---|
invalid_request | Missing required parameter |
invalid_client | Invalid client ID or secret |
invalid_grant | Invalid or expired authorization code |
unauthorized_client | Client not authorized for this grant type |
unsupported_grant_type | Grant type not supported |
invalid_scope | Requested scope is invalid or unknown |
access_denied | User denied authorization |
Best Practices
Secure Token Storage
Secure Token Storage
- Store tokens securely (encrypted database or secure storage)
- Never expose tokens in URLs or logs
- Use HTTPOnly cookies for browser-based apps
- Implement token encryption at rest
Token Refresh Strategy
Token Refresh Strategy
- Refresh tokens proactively before expiration
- Implement automatic retry with refresh on 401 errors
- Handle refresh token expiration gracefully
- Queue API requests during token refresh
State Parameter Usage
State Parameter Usage
- Always use the state parameter for CSRF protection
- Generate cryptographically random state values
- Store state server-side or in session
- Verify state matches on callback
Scope Management
Scope Management
- Request only the scopes you need
- Explain scope usage to users clearly
- Handle scope changes gracefully
- Re-authorize if you need additional scopes
Testing OAuth Flow
Use the OAuth playground to test your implementation:- Visit the OAuth Playground
- Enter your client ID
- Select scopes
- Test the authorization flow
- Inspect tokens and responses
Rate Limits
OAuth-authenticated requests have higher rate limits:- OAuth Client: 500 requests per 60 seconds
- Access Token: 500 requests per 60 seconds
Migration from API Keys
If you’re migrating from API keys to OAuth:- Create an OAuth client
- Implement the authorization flow
- Update API requests to use access tokens
- Test thoroughly before switching production traffic
- Maintain API key support during transition
Example Implementation
Next Steps
Rate Limits
Learn about OAuth rate limits
Webhooks
Set up event notifications
API Reference
Browse all available endpoints
Security Best Practices
Implement security measures