Information
- License: Apache-2.0
- OpenAPI version:
3.1.0
Overview
Registry Scheduling API v1alpha2
Section titled “Registry Scheduling API v1alpha2”Implemented Scheduling HTTP contract: published openings, exact-time offerings over interchangeable resource pools, published arrival windows with channel subquotas, holds, and accountable bookings. Mutating authority is a complete task grant; every refusal is one problem from the closed vocabulary.
Authentication
Section titled “Authentication”bearerAuth
Section titled “bearerAuth”A fresh access token from the configured issuer, for this deployment’s audience, signed by a key the issuer published. Catalogue, availability, and ordinary owned-record reads demand the configured reads scope (scheduling:read by default); the explain path demands the configured explain scope (scheduling:explain by default), which is never the reads scope. Source-manager detail accepts appointment.read with the exact retained manager and service/location binding and fresh online status, without a general reads scope. The operational work list demands exactly one explicitly configured operational profile; catalogue scopes and task grants never authorize it. A mutating route demands no scope at all: its authority is the complete task grant the token carries, whose scheduling permissions the service checks against the offering’s service and location and the action the route performs (hold.create, hold.release, appointment.create, appointment.reschedule, appointment.cancel, attendance.record). Source-managed creation instead uses hold.create-for or appointment.create-for and always checks fresh online status. A token with partial grant claims is refused rather than half-trusted.
Security scheme type: http
Bearer format: JWT