Bookings

Lifecycle

DRAFT  ──────────────────────────────────► SCHEDULED
  │                                            │
  │                                            ├─► COMPLETED
  │                                            ├─► CANCELLED
  │                                            ├─► NO_SHOW
  │                                            └─► RESCHEDULED ──► SCHEDULED
  │
  └─► PENDING_CONFIRMATION ─────────────► SCHEDULED
                            └──────────► CANCELLED

Status	Description
`DRAFT`	Created; routing in progress (transient — typically resolves in milliseconds)
`SCHEDULED`	Assigned to a team member, confirmed
`PENDING_CONFIRMATION`	Waiting for host to confirm (`requires_confirmation: true` on the event type)
`RESCHEDULED`	Active booking at a new time (original booking moves to `CANCELLED`)
`COMPLETED`	Meeting took place
`CANCELLED`	Cancelled by host, attendee, or API
`NO_SHOW`	Attendee did not show up

Create a booking

POST /v1/bookings

{
  "event_type_id": "evt_01abc",
  "requested_time": "2026-05-01T14:00:00Z",
  "attendee": {
    "name": "Jane Smith",
    "email": "jane@example.com",
    "phone": "+1-555-0123",
    "timezone": "America/New_York"
  },
  "custom_fields": {
    "company": "Acme Corp",
    "topic": "Product demo"
  },
  "metadata": {
    "source": "website",
    "campaign": "spring-promo"
  }
}

Returns 201 Created on success. See Idempotency for retry-safe creation.

Get a booking

GET /v1/bookings/{id}

List bookings

GET /v1/bookings?status=SCHEDULED&start_date=2026-05-01T00:00:00Z&limit=25

Prop	Type	Default
`status`	`string`	-
`event_type_id`	`string`	-
`assigned_to_id`	`string`	-
`attendee_email`	`string`	-
`start_date`	`ISO 8601`	-
`end_date`	`ISO 8601`	-
`limit`	`integer`	`50`
`cursor`	`string`	-

Bookings use cursor-based pagination. Pass pagination.next_cursor from any response as the cursor param on the next request:

{
  "success": true,
  "bookings": [...],
  "pagination": { "next_cursor": "bkg_01xyz", "has_more": true }
}

When has_more is false, you have reached the last page and next_cursor is null.

Update attendee details

PATCH /v1/bookings/{id}

Only attendee fields can be patched (name, email, phone, timezone). Scheduling fields (time, status, assignment) are rejected.

Allowed states: SCHEDULED, RESCHEDULED, PENDING_CONFIRMATION.

{ "attendee": { "email": "new@example.com" } }

If the email changes, a fresh confirmation email is sent to the new address. Ensure this is intentional before patching.

Status transitions

Transitions PENDING_CONFIRMATION → SCHEDULED. Naturally idempotent — calling on an already-confirmed booking returns the current state.

POST /v1/bookings/{id}/confirm

Idempotency

Pass an Idempotency-Key header on POST /v1/bookings to safely retry without creating duplicates:

curl -X POST https://api.slatis.com/v1/bookings \
  -H "Authorization: Bearer sk_live_xxx" \
  -H "Idempotency-Key: order_12345_attempt_1" \
  -H "Content-Type: application/json" \
  -d '{ ... }'

First call: creates the booking, returns 201 Created
Duplicate call (same key): returns 200 OK with "idempotent_replay": true and the byte-identical original response body
Keys are scoped per team — two teams may reuse the same key string independently
Keys expire after 24 hours

Status transition endpoints (confirm, complete, no-show, cancel) are inherently idempotent — repeating the same operation returns the current state without side effects. No idempotency key needed.