canonical: https://jentic.com/apis/onsched.com

# OnSched APIs

OnSched is a developer-first online booking platform. Its APIs split into three surfaces: a Setup API that configures companies, calendars, services, resources, and business rules; a Consumer API that searches availability and creates, books, reschedules, and cancels appointments for end users; and a Utility API that exposes heartbeat and thread-info health checks. Together they cover the full path from provisioning a booking backend to taking real bookings and monitoring that the platform is up. All three share OAuth 2.0 client-credentials authentication bound to a company profile.

## For AI agents

An agent can provision a booking tenant end to end, configuring companies, calendars, services, and business users, then search availability and book, reschedule, or cancel appointments for real customers, and gate that work on a platform health check before it runs.

## Scope

Use for: Building and operating a multi-tenant appointment-booking backend: configuring companies, calendars, services, and resources, searching availability and booking appointments for end users, and monitoring OnSched platform health.

Not supported:
- payment processing
- hosted booking pages
- video conferencing
- customer messaging delivery
- on-prem deployment

## APIs

| API | Category | Endpoints | Description |
| --- | --- | --- | --- |
| OnSched Setup API | productivity | 139 | Configure companies, services, resources, calendars, and business rules that back OnSched booking flows using OAuth 2.0 client-credentials authentication. |
| OnSched Consumer API | productivity | 38 | Search availability, create and book appointments, and manage customer records for online booking flows using OAuth 2.0 client-credentials authentication. |
| OnSched API Utility | developer-tools | 2 | Confirm OnSched platform health with heartbeat and thread-info checks using OAuth 2.0 client-credentials authentication. |

## Which API to use

| Need | API | Why |
| --- | --- | --- |
| Configure companies, calendars, services, resources, and business users | setup | The Setup API owns tenant provisioning and admin-side calendar, block, and appointment-reassignment operations across 139 endpoints. |
| Search availability and book, reschedule, or cancel appointments for end users | consumer | The Consumer API is the booking surface that operates on an already-configured profile, with availability search and appointment lifecycle actions. |
| Confirm the OnSched platform is reachable before issuing booking or provisioning calls | utility | The Utility API exposes heartbeat and thread-info health checks and is the lightest call to gate a workflow on. |

## Cross-API use cases

### Provision a tenant, then take live bookings

A vertical SaaS onboards a new customer by creating the company, calendars, services, and business users through the Setup API, then switches to the Consumer API to search availability and book appointments for that tenant's end users. Both APIs run under one OAuth client-credentials domain, so the same agent handles configuration and booking without a second credential.

Example prompt: POST /setup/v1/companies and /setup/v1/calendars for the new tenant, then GET /consumer/v1/availability/{serviceId}/{startDate}/{endDate} and POST /consumer/v1/appointments to take a booking.

### Health-gated booking concierge

An AI scheduling assistant checks that OnSched is reachable via the Utility API heartbeat before it searches availability and books an appointment through the Consumer API. Gating the booking on a healthy response stops the agent from issuing failing calls during an OnSched incident.

Example prompt: GET /utility/v1/health/heartbeat and only on a healthy response run GET /consumer/v1/availability/{serviceId}/{startDate}/{endDate} then PUT /consumer/v1/appointments/{id}/book.

### Pre-flight check before a provisioning batch

Before a nightly job creates many companies and calendars through the Setup API, a downstream system runs a Utility API heartbeat to confirm the platform is healthy enough to accept the work, avoiding partial-success batches that need manual reconciliation.

Example prompt: GET /utility/v1/health/heartbeat, abort on a degraded response, otherwise POST /setup/v1/companies and /setup/v1/calendars for each tenant in the batch.

## Why Jentic

- **Setup:** Wiring OnSched by hand means running the OAuth 2.0 client-credentials flow, tracking token expiry, and calling three separate surfaces for setup, booking, and health. With Jentic you install Jentic One once, add the OnSched APIs you need from the Jentic directory, store the client credentials once, and your agent calls them.
- **Permission scoping:** OnSched puts calendar and appointment ids in the URL path, so your own rules can pin the agent to specific operations and resources. You decide whether it can only read health and availability, or also provision companies and book, so account-shaping calls are not available unless you add them.
- **Credential handling:** Your OnSched client credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context, and the same credential covers all three OnSched APIs.
- **Discovery method:** Agents search the Jentic directory by intent such as 'create an onsched company', 'book an appointment', or 'check that onsched is reachable', and Jentic returns the matching OnSched operation with its input schema so the agent calls the right endpoint across the three APIs.

## Related vendors

- **Calendly** — Hosted scheduling product for teams that want a booking page with minimal configuration rather than an embeddable backend.
- **Acuity Scheduling** — Scheduling API aimed at single small-business service providers that do not need OnSched's multi-tenant company model.
- **Cal.com** — Open-source scheduling platform with an API, an alternative for teams that want to self-host their booking layer.

## FAQ

### What can an agent do across the OnSched APIs?

An agent can run the whole booking lifecycle. It can provision a tenant with the Setup API by creating companies, calendars, services, resources, and business users, then take live bookings with the Consumer API by searching availability and creating, booking, rescheduling, or cancelling appointments, and it can gate that work on a platform health check from the Utility API.

### Do the three OnSched APIs share one credential?

Yes. Setup, Consumer, and Utility all use the same OAuth 2.0 client-credentials scheme, with a ClientId and Secret bound to a company profile. One credential set authenticates against all three, so an agent does not manage separate secrets per API.

### Which OnSched API should I start with?

Start with the Setup API if you need to configure a booking backend, since companies, calendars, services, and resources must exist before bookings can be made. Use the Consumer API once a profile is configured and you want to search availability and book for end users. Use the Utility API for health checks and readiness gates.

### How do the OnSched APIs fit together in one workflow?

The Setup API stands up the configuration that the Consumer API books against, and the Utility API monitors that the platform is up. A common flow is to provision a tenant with Setup, take bookings with Consumer, and run a Utility heartbeat before large batches or during incidents.

### Is OnSched a hosted scheduling page?

No. OnSched is a configurable, multi-tenant booking backend that you embed in your own storefront, mobile app, or agent. It exposes the admin configuration surface, the consumer booking surface, and the health surface as separate APIs rather than a single hosted booking page.

### What is OnSched not suited for?

OnSched does not process payments, deliver customer messaging, or provide video conferencing, and it does not offer a hosted booking page in place of your own front end. Pair it with a payments, messaging, or video provider when a workflow needs those steps.