API-first
Every HTTP interface is specified in OpenAPI before it is implemented. The SDK is generated from that specification rather than written by hand, so the client cannot describe an endpoint the server does not have.
Platform
One engine underneath every surface.
ZenOrbit is a platform first and an application second. Scheduling, availability, commerce and identity are implemented once, behind a versioned API, and every surface — the web app, the mobile app, an integration you build — is a client of the same contract.
Capabilities
Available today
Everything on this page is implemented and running in production. Where something is planned rather than built, it is on the products page, labelled as such.
-
Scheduling and bookings
Define what can be booked, publish a page for it, and let the platform hold the invariants. An appointment that overlaps an existing one cannot be created, and availability is resolved from connected calendars rather than from a static grid.
-
Availability control
Availability is a first-class model, not a filter applied at display time. Working hours, buffers either side of an appointment, minimum notice, and how far ahead someone may book are all enforced when the booking is created.
-
Meetings
A confirmed booking produces a real conference link from the provider connected to that event type. The link is created through the provider’s own API at booking time, so it exists before the invitation is sent.
-
AI meeting assistant
The assistant proposes; it never files anything on its own. Summaries are attached to the meeting record for the participants to read, correct or ignore.
-
Webinars
Registration, attendee limits and paid entry run on the same commerce and notification machinery as one-to-one bookings, rather than a parallel implementation that would drift.
-
Payments and commerce
Orders, payments, tax, fees, earnings and refunds are recorded in a ledger that reconciles against the payment provider on a schedule. Disagreements are surfaced for a person to judge — nothing silently repairs itself.
-
Subscriptions and billing
Feature access is resolved from subscription state held by the platform, so entitlement is consistent across every surface rather than re-derived by each client.
-
Teams and workspaces
Team scheduling distributes bookings by rule rather than by hand: round robin to spread load, collective events where several people must attend, and routing rules that send a request to the right person based on what the requester answered.
-
Public profiles
A public profile is the front door for someone who has never signed in. It lists what can be booked and carries testimonials gathered after past sessions.
-
Notifications
Reminders are driven by domain events rather than by polling, so rescheduling a booking updates its reminders as a consequence of the reschedule.
-
Calendar integrations
Connected calendars are read for busy time and written to when a booking is confirmed, so the appointment exists in the calendar the person actually looks at.
-
Developer platform
The API contract is defined before the implementation and published as an OpenAPI specification; the TypeScript SDK is generated from it rather than written by hand. An MCP server exposes the same capabilities to AI agents.
Integrations
Connected to the calendar you already keep.
Each of these has a real adapter running in production. A provider without one is not listed here, and is not offered inside the product either.
Calendars
Read for busy time, written to when a booking is confirmed.
Conferencing
A real join link is created through the provider’s API at booking time.
How it is built
The decisions that make it predictable.
These are architectural commitments, not features. They are the reason the product behaves the same way on the tenth thousand booking as on the first.
Domain-driven
Business rules live in domain objects that validate themselves. An appointment ending before it starts is not a validation message — it is a state the code cannot construct.
Event-driven
State changes publish domain events. Reminders, cache invalidation and downstream effects consume them, so a rescheduled booking updates everything that depended on the old time.
Multi-tenant by construction
Isolation is resolved from the authenticated principal on every request and never accepted from client input. It is applied at the data layer, not in a filter a query can forget.
Idempotent by default
Webhooks, retries and duplicate submissions are expected. A redelivered payment event is acknowledged without being applied twice, which is what keeps the ledger honest under network failure.
Observable
Structured logs, distributed traces and per-domain metrics on every request. Secrets, tokens and personal data are never written to a log, in any form, including masked.
For developers
Build on it directly.
The same API the ZenOrbit apps use is available to you, versioned in the URL path with a stated deprecation policy — additions never break a running integration, and removals are announced with a sunset date long before they happen.
REST API
Versioned endpoints covering scheduling, availability, bookings, meetings, commerce and billing, with a consistent error envelope and a trace identifier on every response.
OAuth 2.0
Machine access via client credentials. An application is registered once, and its tenant context is resolved from that registration rather than from anything it sends.
MCP server
An implementation of the Model Context Protocol, so an AI agent can work with scheduling data through the same contracts and the same authorisation as any other client.
See the platform in your own calendar
The free plan connects a real calendar and takes real bookings. Nothing is simulated.