For Developers

Add scheduling to your product.

Query available times, create bookings, and receive signed webhooks through Slotkit's server-side API.

Slotkit still checks Google Calendar for busy times and writes booking events there, including API-only use.

Ways to integrate

Slotkit exposes the same scheduling capabilities through a hosted booking page and a versioned server-side API. These are two entry paths into one product, not separate editions.

Custom booking UI

Present available times in your product and submit bookings through your backend.

Never place Tenant API Keys in browser code.

Existing application

Add booking creation, rescheduling, and cancellation to an existing service.

Follow key scopes, idempotency, and concurrency requirements.

External workflows

Consume lifecycle webhooks to update your own systems.

Slotkit does not provide a general workflow builder.

Hosted plus API

Use a booking page and integrate the same configured scheduling resources where useful.

Hosted access rules and API authorization remain distinct.

The minimal integration flow

  1. 01

    Query available times

    Ask which slots are bookable for an event type at a point in time.

  2. 02

    Create the selected booking

    Submit the chosen slot with a unique idempotency key and the guest details.

  3. 03

    Process lifecycle events

    Receive signed Booking and Calendar lifecycle webhooks.

A displayed slot is not held. It can become unavailable before the create call confirms; handle that conflict response.

POST /v1/bookings

Authorization: Bearer sk_live_2f81c4…
Idempotency-Key: 0f4a9d12-6c33-4b7e-9a10-8ee2c5d17b40

{
  "event_type_id": "evt_3n8xqk2r",
  "start_at": "2026-09-14T02:00:00.000Z",
  "guest": {
    "name": "Mei Lin",
    "email": "[email protected]",
    "timezone": "Asia/Taipei"
  }
}

201 Created

{
  "data": {
    "id": "bkg_7pd4m1vs",
    "status": "confirmed",
    "version": 1,
    "source": "api",
    "start_at": "2026-09-14T02:00:00.000Z",
    "end_at": "2026-09-14T02:30:00.000Z",
    "calendar": { "status": "pending", "error_code": null },
    "meeting": { "type": "google_meet", "join_url": null }
  },
  "meta": { "request_id": "req_a71c9f04" }
}

The booking is confirmed in the same response that reports the calendar event as pending. Confirmation does not wait for the calendar event to be written.

What the API surface includes

  • Versioned /v1 REST contract and server-side API keys with fixed scopes.
  • Availability queries and booking creation, rescheduling, and cancellation.
  • Booking Invitation listing, creation, revocation, and reissue for invitation-only pages.
  • Bounded metadata for application-owned context, with no scheduling or authorization semantics.
  • A server-side TypeScript SDK built for the implemented contract.
  • Signed booking.created, booking.rescheduled, booking.cancelled, calendar.created, and calendar.failed webhooks.

The v1 contract is stable and available through the API reference. The TypeScript SDK is implemented at version 1.0.0 but is not publicly distributed yet.

What your integration must plan for

Safe request replay
Mutation idempotency prevents an accepted retry from creating another booking. Conflicts and changed requests still need explicit handling.
Booking versus side effects
Calendar synchronization and webhook delivery follow committed state. Their delay does not undo the booking.
Availability dependency
Availability checks can fail closed when Google Calendar is unavailable and no valid recent snapshot exists.
Concurrent booking
A slot can become unavailable between query and submission. Integrations must handle that response.
Delivery model
Webhooks can be retried and delivered more than once. Verify signatures and deduplicate using the documented event identity.
Recovery
Retries are bounded. Failed synchronization or delivery may require an authorized recovery action.
Inspect the API reference →

Credentials and isolation

  • API keys live in your server environment, never in browser code.
  • Scopes are fixed and least-privilege; request only what the integration uses.
  • Webhook deliveries are signed; verify the signature before trusting an event.
  • Each workspace sees only its own data. Cross-workspace access is rechecked server-side.
How Slotkit protects credentials →

Resources

Use the interactive API reference or download the OpenAPI document to evaluate the v1 contract. Public distribution of the TypeScript SDK is not available yet.

Questions

Before you integrate.

Can I use Slotkit without the hosted booking page?

Yes. The same event types and availability are readable and bookable server to server with a scoped API key.

Where must the API credential live?

Server-side only. Tenant API keys must never be embedded in browser code; calls go through your own backend.

Does the API still require Google Calendar?

Yes. Google Calendar remains required for bookability, including API-only use, because availability checks and booking events depend on it.

Are webhooks delivered exactly once?

No. Deliveries can be retried and can arrive more than once. Verify signatures and deduplicate using the event identity.

Can a browser talk to the API directly?

Not with API keys. A custom booking UI submits through your own application backend, which holds the credential.

Can guests use the hosted page while my integration uses the API?

Yes. Hosted access rules and API authorization remain distinct, and both operate on the same scheduling resources.