OnSched API 3.24.0 — Calendar sync adapters
External calendar sync
Sync adapters send no notifications. Outlook bookings go to the selected calendar and store UTC.
The booking writer does not call these sync adapters yet. A Google booking that
includes a guest still notifies that guest when the caller does not pass
sendUpdates.
Manual resync queues upcoming booked appointments through the sync adapters
and does not add customer attendees or send provider invitations. Each Resource
keeps its own event. Sync does not copy an appointment that has already
started, and it creates a padding event only when a stored padding intent
exists. An Outlook event that already has attendees is left in place and
unlinked locally.
POST /v3/resource/{id}/externalCalendars/resync queues that resync. The
response is 202 with jobId, status, statusUrl, and reused.
GET /v3/resource/{id}/externalCalendars/syncJobs/{jobId} returns counts and
sanitized failure reasons. An equivalent active job is reused. A second new
manual job for the same resource within a minute returns 429. Calendar
selection tokens cannot call these routes. Outlook discovery for one job reads
the OnSched category once, with the appointment extension expanded, and reuses
that list for transaction, V1, and V3 matching.
Connecting a writable Google calendar, choosing or changing the write calendar,
enabling write, or connecting an application Outlook mailbox queues that same
upcoming-booked sync. A read-only Google connection still succeeds. Its
writeGranted value stays false, and no backfill is queued. Enabling write
then returns CALENDAR_WRITE_NOT_GRANTED with a reconsent path. Pending OAuth
setup does not queue a backfill. Appointments that already started, and
historical padding, are skipped. An equivalent active job is reused.
Add a service from Services
Add Service on the Services page no longer fails when no location is selected. The portal omits the locations query. For a company-scoped service, that is the company-level create: every company location is linked. Creating a service while a location is selected still links that location only.
Location association lists
POST /v3/location/{id}/setAssociations rejects resources: null and services: null with a 400 validation error. Existing links stay in place. An empty array still clears that relation. An omitted key is left unchanged.
