How to cal API v2

[alexcoopper]

Hi.
I have configured helm chart to deploy the cal.com on my kubernetes cluster.

Here it the values.yaml with important settings:

postgresql:
auth:
username: caladmin
password: calpass123
database: calcom
primary:
persistence:
enabled: true
size: 8Gi

calcom:
image:
repository: calcom/cal.com
tag: v5.5.3
pullPolicy: IfNotPresent

service:
type: NodePort
# web UI
port: 3000
nodePort: 30080
# API-v2
extraPorts:
- name: api-v2
port: 5555
targetPort: 5555
nodePort: 30671
protocol: TCP

envFrom:
secretRef: calcom

env:
# database
DATABASE_URL: "postgres://caladmin:calpass123@calcom-stack-postgresql:5432/calcom"

# front-end URLs
NEXT_PUBLIC_WEBAPP_URL:  "http://localhost:3000"
NEXT_PUBLIC_API_V2_URL:  "http://calcom-stack:5555/api/v2"

# disable localhost proxy
NEXT_PUBLIC_USE_PROXY:   "false"

# allowed hosts
ALLOWED_HOSTNAMES:       "\"localhost\""

# auth & encryption
NEXTAUTH_SECRET:         "supersecretstring1234567890"
CALENDSO_ENCRYPTION_KEY: "yoursecretkeymustbe32bytes!!"
CALCOM_LICENSE_KEY:      "1a1f8138-0bfc-4f37-b4af-1e24fd145839"
CAL_SIGNATURE_TOKEN:     "1a1f8138-0bfc-4f37-b4af-1e24fd145839"

createCalcomSecret: true

I have a few questions:

1. Can I use cal.com API as a free service, like: get API Key by API, create a user, create availability slotes, configure sync with calendars, copy embed snippet etc.?
2. Hot to obtain the API key except UI (It seems it's bloked on UI)
3. Why I cannot call the API?
   By calling the
   GET http://localhost:30080/api/v2/me or GET http://localhost:3000/api/v2/me in the container I got the error:
   @calcom/web:start: Failed to proxy http://localhost:5555/api/v2/me⁠ Error: connect ECONNREFUSED ::1:5555

@calcom/web:start: at (Error: connect ECONNREFUSED ::1:5555) {

@calcom/web:start: errno: -111,

@calcom/web:start: code: 'ECONNREFUSED',

@calcom/web:start: syscall: 'connect',

@calcom/web:start: address: '::1',

@calcom/web:start: port: 5555

@calcom/web:start: }

@calcom/web:start: Error: connect ECONNREFUSED ::1:5555

@calcom/web:start: at (Error: connect ECONNREFUSED ::1:5555) {

@calcom/web:start: errno: -111,

@calcom/web:start: code: 'ECONNREFUSED',

@calcom/web:start: syscall: 'connect',

@calcom/web:start: address: '::1',

@calcom/web:start: port: 5555

@calcom/web:start: }

[dosubot[bot]]

Hi @alexcoopper! I'm Dosu and I’m helping the cal.com team.

Your ECONNREFUSED error on port 5555 is almost certainly because the API v2 service isn't running or is missing a required environment variable. Redis is mandatory for Cal.com API v2—make sure you set the REDIS_URL environment variable (for example, REDIS_URL=redis://localhost:6379). Without this, the API v2 server won't start and nothing will listen on port 5555, which matches the error you're seeing. Double-check that the API v2 pod/container is healthy and actually running on the expected port in your cluster. More details are in this discussion: Redis is mandatory for API v2.

For API key management: there is no documented way to obtain an API key via API or CLI—API keys are managed through the UI, and there are no threads or docs showing a supported alternative if the UI is blocked.

For licensing: to run API v2, you must set a valid CALCOM_LICENSE_KEY in your environment and database, but there is no documentation clarifying restrictions on free usage for actions like user creation, availability management, calendar sync, or embedding. The API v2 endpoints for booking slots and calendar sync are documented here: API v2 slots documentation.

If you need to troubleshoot further, check the logs for the API v2 pod/container and verify all required environment variables are set, especially REDIS_URL and CALCOM_LICENSE_KEY (setup info).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[dosubot[bot]]

API v1 does not have the same license key restrictions as API v2. Based on the code and available discussions, API v1 does not enforce CALCOM_LICENSE_KEY or commercial gating—there are no license checks in the v1 routes or middleware, unlike v2 where these are clearly present. This means you can use API v1 for free in a self-hosted environment, at least for the core endpoints and features provided by v1. You can find more details and the API v1 documentation here: API v1 README and related discussion.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[alexcoopper]

@dosu but the documentation says I have to generate a key in the same settings/security section. So it has the same restriction!

[dosubot[bot]]

You're right—the API v1 does require an API key, and the only supported way to generate that key is through the UI at the settings/security section, even for self-hosted instances. There isn't a documented or built-in alternative (like CLI or API endpoint) for creating API keys outside the UI. However, API v1 does not enforce license key checks or commercial restrictions like API v2 does—so once you have an API key, you can use v1 endpoints freely in your self-hosted setup. You can see this in the API v1 README, which confirms both the API key requirement and the UI-based generation.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[alexcoopper]

@dosu can I fork the repo, and remove all lisence checks from the code, it's allowed by the license?

[dosubot[bot]]

You can fork the repo and modify or remove license checks from the AGPL v3-licensed parts of the code, as the AGPL v3 allows modification and redistribution, provided you also make your modified source code available to users who interact with your deployment over a network. However, code under packages/features/ee and apps/api/v2/src/ee is covered by a Commercial License, not AGPL, so you cannot legally modify or redistribute those parts unless you have a commercial agreement. There are no explicit restrictions in the AGPL v3 or the repo's LICENSE file against removing license checks from the AGPL-licensed code, but your changes must remain AGPL-licensed and you must not misrepresent your fork as the official Cal.com product. See the LICENSE file for details: LICENSE.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}