Bookings inside your product.

// On your server: a provider, their hours and what can be booked.
await coss.scheduling.hosts.create({
  uid: "tutor_482",
  name: "Ana Reyes",
  email: "ana@example.com",
  time_zone: "America/New_York",
});

await coss.scheduling.schedules.create("tutor_482", {
  rules: [{ days: [1, 2, 3, 4, 5], start: "09:00", end: "17:00" }],
});

const { data: eventType } = await coss.scheduling.eventTypes.create({
  title: "Trial lesson",
  duration_minutes: 30,
  buffer_after_minutes: 10,
  hosts: [{ host: "tutor_482" }],
});

// When a signed-in customer wants to book: a session for their browser.
const { data: session } = await coss.scheduling.sessions.createForBooker({
  event_type: eventType!.id,
  attendee: { uid: "customer_77", name: "Sam Lee", email: "sam@example.com", time_zone: "UTC" },
});
// Hand session.url to the browser.

// In the browser: the booker in an iframe on your own page.
mountBooker({
  url: sessionUrl,
  container,
  onEvent: (event) => {
    if (event.type === "booked") console.log("Booked", event.booking_id);
  },
});

Hosts get the same treatment: coss.scheduling.sessions.createForHost and mountHostPortal put their hours, calendars and bookings on a page in your app. To book from your own UI, list times with coss.scheduling.slots.list and book with coss.scheduling.bookings.create. See the Scheduling guide and the API reference.

Every booking takes a claim on its host's time, with its buffers. A Postgres exclusion constraint, scheduling_claim_no_overlap, refuses any two claims of one host that overlap. It's the only enforcement: slot lists and re-checks just avoid asking a question it would refuse, so there's no gap between checking and writing for a booking to slip through.

When two people go for one time, one gets the booking and the other gets slot_unavailable, and you show them the times again. The same claim backs holds, pending approvals, series and group sessions. Every attempt the SDK retries carries the same Idempotency-Key, so a lost response can't book twice.

Events made outside coss.com are a different case. Something added to a host's calendar can still land on a booked time. The booking stands, coss.com never cancels on its own, and you get scheduling.booking.external_conflict.

coss.com Scheduling is built by the team behind Cal.com, on the same scheduling technology that has processed tens of millions of bookings there. Time zones, availability and calendar connections have already met the real world, and you get them through one API key alongside the rest of coss.com.

From calendars, coss.com stores when they're busy and nothing else: no titles, descriptions or attendees of other events. A booking goes on a host's calendar as a private event titled "Appointment", with no attendees, so their colleagues learn nothing from it.

Attendee contact details and answers are encrypted, and a booking only needs a time_zone, so you can use your own ids rather than names. Answers come back only when you retrieve one booking, never in lists, webhooks, logs, emails or calendars, and webhooks carry ids, times and statuses. coss.scheduling.attendees.erase removes someone's contact details and answers from their bookings right away.

Our Terms don't allow special categories of personal data or protected health information without a written agreement. See privacy for what's stored and for how long.

The Free plan includes 100 scheduling bookings a month. A group session is one booking however many attend, and each occurrence of a series is one. Rescheduling is free, and a cancelled booking stays charged. Booking emails sent from your own domain are billed like any email, and SMS reminders like any text message. See pricing for the plans.

With a sandbox (coss_test_…) key, emails go to the fake provider, so nobody's mailed, and the dashboard shows them with their links. Connect a simulated calendar and set its busy times with coss.scheduling.calendars.setSimulatedBusy, and test your handlers with coss trigger scheduling.booking.confirmed. See testing.