Skip to main content
This guide covers the lifecycle of a scheduling page from the API side — listing what you have, inspecting a single page’s configuration, activating or deactivating it, and issuing single-use links to share with specific customers. If you want to use a scheduling page (fetch availability and create a booking), see the Booking Flow guide. This guide is its complement: it covers how you manage the pages themselves.

When to use these endpoints

Typical reasons to manage scheduling pages programmatically:
  • Provisioning at sign-up — list a newly invited user’s pages to confirm they exist before pointing the user at them.
  • Syncing from a master config — keep an internal source of truth in step with what’s published on Zeeg by toggling pages active/inactive as your data changes.
  • Per-customer booking links — issue a unique, one-time-use link to a specific customer (for example, after a paid signup) so they can only book once.
  • Operational hygiene — deactivate an employee’s scheduling page when they leave; reactivate when they return.

Prerequisites

  • An API token from your Zeeg dashboard. All endpoints in this guide require a Bearer token.
  • The userSlug filter on listing requires an organization admin or owner token.
Naming. Zeeg’s dashboard calls these “scheduling pages.” The API path is /event-types for historical reasons. The two terms refer to the same object — this guide uses “scheduling page” in prose and shows the actual /event-types path in code samples.

Listing scheduling pages

Retrieve a paginated list of scheduling pages with GET /event-types. By default, the response contains pages on which the authenticated user is a host.

Query parameters

Example response

The response uses Zeeg’s standard pagination envelope. Walk through pagination.nextPage until it returns null — see Pagination for the full pattern.
To audit pages owned by another user in your organization (for example, when offboarding), call GET /event-types?userSlug=<slug> with an admin token.

Getting a single page’s details

Fetch a specific scheduling page by UUID with GET /event-types/{uuid}. The detail response is richer than the list response — it includes notification settings, the assigned hosts (or Flexi host collections), and the full inviteeQuestions array.

Fields most integrations care about

For the complete schema, see the Get a scheduling page API reference.

Toggling active/inactive

Send PUT /event-types/{uuid}/status to flip a page’s active state. The endpoint takes no body — it toggles whatever the current state is. Active pages accept bookings; inactive pages do not appear at the public URL and reject API bookings.

Example response

This endpoint toggles — it does not let you set an explicit target state. If you need to ensure a page ends up active (or inactive) regardless of its current state, fetch the page first, check isActive, and only call the toggle endpoint when the current state differs from your target.
Python
A single-use link lets you give a specific customer a unique URL that can be redeemed exactly once. After the booking is confirmed, the link can no longer be used. This is the most powerful programmatic feature exposed on scheduling pages — use it any time you want to bind a single booking to a specific recipient (post-purchase scheduling, support escalations, gated demo invites, etc.). Generate one with GET /event-types/{uuid}/single-use-link.

Query parameters

Example response

The link field contains the URL to share with the recipient. Once they complete a booking through it, the link is consumed and any subsequent attempts to use it will fail.
Each call to GET /event-types/{uuid}/single-use-link returns a new link. Generate one link per recipient — never reuse the same single-use link for two different people.
A common pattern is to mint a single-use link the moment a customer completes a paid signup, then email it to them so they can book a kickoff call exactly once.
Don’t mint single-use links until you actually need them. Generating one for every record in a CRM list “just in case” creates URLs that may sit unused — and you’ll have no easy way to map them back to recipients later. Mint on demand, log the recipient alongside the link, and let the invitee.scheduled webhook tell you when each link has been consumed.

Composing with the booking flow

Once you have a scheduling page (or a single-use link), the next step is fetching availability and creating the booking. That’s covered end-to-end in:

Booking Flow

Fetch a scheduling page’s available slots and create a booking via the API.

Rate limits and error handling

  • All endpoints in this guide return standard Zeeg error codes — see Errors for the full list and recommended client behaviour.
  • API requests are subject to per-token limits — see Rate Limits before bulk-issuing single-use links or syncing many pages.
  • A 404 from the toggle or single-use-link endpoints means the UUID does not match a scheduling page accessible by your token. Double-check the UUID and the token’s owner.
Last modified on May 7, 2026