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
userSlugfilter 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 withGET /event-types. By default, the response contains pages on which the authenticated user is a host.
Query parameters
Example response
pagination.nextPage until it returns null — see Pagination for the full pattern.
Getting a single page’s details
Fetch a specific scheduling page by UUID withGET /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
SendPUT /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
Python
Issuing single-use links
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 withGET /event-types/{uuid}/single-use-link.
Query parameters
Example response
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.
Worked example: issue a link on customer signup
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.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
404from 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.