How Developers Can Integrate Cal.com into Their Own Apps or Websites

Cal.com offers four developer-facing integration paths, each suited to a different level of control: a public API for building custom integrations, React scheduling components ("atoms") for embedding scheduling UI directly into a React app, OAuth clients for connecting your product to a user's Cal.com account, and a plain embed option for dropping Cal.com into an existing website. Which one you pick depends on whether you want to own the scheduling UI, just the data flow, or neither.

The four integration options at a glance

All four are documented under the Developer section of cal.com, alongside the API reference and component docs.

Building with the public API

The API is the most flexible option and the right starting point if your frontend isn't React, or if you need scheduling data to flow into your own system rather than render Cal.com's UI.

The general shape of the work:

1. Read the API documentation at the Developer → Documentation entry on cal.com to see the available endpoints and authentication requirements.
2. Authenticate your requests using the method the docs specify for your use case — note that OAuth is a separate, documented path (see below) if you're acting on behalf of other users.
3. Call the endpoints you need and handle responses in your own application logic.

Expected result: your application can create, read, or react to scheduling data without the user ever seeing a Cal.com interface. The specific endpoint list and auth details live in the docs, so treat those pages as the source of truth rather than guessing at paths.

Embedding scheduling UI with React atoms

If you're building a React app and want booking to feel like part of your product, Cal.com's scheduling components are the intended route. The site describes them as "react atoms" you use to add scheduling to your app — the idea being that you compose small scheduling primitives rather than iframing a whole booking page.

Use this when:

• Your app is already React.
• You want control over layout and styling around the scheduling step.
• You'd rather not maintain your own calendar and availability logic.

If your app isn't React, skip to the API or embed options instead — the atoms are React-specific by description.

Integrating via OAuth

OAuth is the option to reach for when your product needs to act on a Cal.com user's behalf — for example, a tool that reads their availability or creates bookings in their account after they grant permission.

The documented flow is "Create OAuth Client," which implies you register a client with Cal.com and then integrate using OAuth. Practically, that means:

1. Register your OAuth client through the developer resources on cal.com.
2. Implement the standard OAuth authorization flow in your app.
3. Use the granted access to call Cal.com on the user's behalf.

This is the right choice for multi-user products where each customer connects their own Cal.com account. It is not needed if you're only embedding a booking page for yourself.

Embedding Cal.com into a website

The simplest path: Cal.com provides an Embed resource specifically for putting Cal.com into your website. This suits marketing sites, landing pages, and any case where you just want visitors to book without building custom UI.

Choose embed over the API when you don't need the booking data inside your own application — you just need the booking to happen. Choose the API or atoms when the scheduling step has to be wired into your product's own state and logic.

How to decide

• Non-React app, need data in your system → Public API.
• React app, want native booking UI → Scheduling components (React atoms).
• Multi-user product acting on behalf of Cal.com accounts → OAuth client.
• Just need a booking form on a site → Embed.

These aren't mutually exclusive — a product could embed a booking page for end users while using the API server-side to sync confirmed meetings.

Common sticking points

• Confusing OAuth with API keys. OAuth is for acting on behalf of other users; if you only need your own account's data, you likely don't need the OAuth client flow.
• Reaching for atoms in a non-React codebase. The components are React-based; other stacks should use the API or embed.
• Assuming embed gives you the data. Embedding puts the booking UI on your page, but pulling that booking into your own database is an API concern.
• Skipping the docs. Endpoint names, scopes, and component props change; the Developer → Documentation and Scheduling Components pages on cal.com are the authoritative references.

Start with the docs page that matches your stack, confirm the authentication model before writing integration code, and pick the lightest option that still gets scheduling data where you need it.