OnSched 3.19.0 - hosted calendar selection

Hosted calendar selection

• OAuth callback: With useOnSchedCalendarSelection: true, GET /v3/calendar/callback stores provider tokens, then 302 redirects to the merchant portal /calendar-select with a short-lived opaque code plus resourceId, externalCalendarId, provider, and optional email. Omitted or false preserves the existing direct returnUrl redirect, or authenticated picker when no return URL is set.
• Exchange code: POST /v3/calendar/selectionSession (no auth) accepts { "code": "..." } and returns a Calendar Selection Token plus connection facts, including the returnUrl bound at connect time. Unsigned returnUrl query parameters on the exchange request are ignored.
• Picker APIs: Use the Calendar Selection Token as Authorization: Bearer … on GET …/externalCalendars/list, POST …/externalCalendars/select, and DELETE …/externalCalendar/:id for that resource connection. Existing machine/dashboard selection APIs remain available.
• Optional returnUrl: For opted-in hosted selection, pass returnUrl on POST /v3/resource/:id/externalCalendar (or when creating a Resource with nested ExternalCalendars) to send the resource's browser back to your app after they save or skip calendar selection. OnSched merges non-secret facts (resourceEmail, provider, externalEmail, externalCalendarId) into that URL. Return destinations must use HTTP or HTTPS. The exchange code and JWT never appear on returnUrl.
• OnSched operations: Set CALENDAR_SELECTION_JWT_SECRET in every API environment. Customers using the hosted service do not generate or supply this secret. Missing or blank values fail closed for opted-in callback exchange and token mint; legacy callbacks do not depend on it.

See External Calendar Sync and Authentication.