Unreleased documentation. These pages follow the main branch and can change before the next release. For supported guidance, use v0.26.1.
Describe this Scheduling deployment
const url = 'https://scheduling.example.test/v1/scheduling';const options = {method: 'GET', headers: {Authorization: 'Bearer <token>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url https://scheduling.example.test/v1/scheduling \ --header 'Authorization: Bearer <token>'Answers the deployment identifier, the current authored policy revision, and its digest, so a caller can detect that the policy it read has since moved. Reading it grants no catalogue, availability, or booking authority.
Authorizations
Section titled “Authorizations”Parameters
Section titled “ Parameters ”Header Parameters
Section titled “Header Parameters”Optional W3C trace context continued in the response.
Responses
Section titled “ Responses ”Success
object
Examplegenerated
{ "policyDigest": "example", "policyRevision": 1, "schedulingId": "example"}Headers
Section titled “Headers”Every answer is marked no-store, so a booking view is never served from a cache.
W3C trace context for the request and response.
Problem response: authentication.refused
object
Example
{ "code": "authentication.refused", "detail": "The bearer credential is missing, invalid, or expired. Sign in again.", "status": 401, "title": "Authentication refused", "type": "https://id.registrystack.org/problems/registry-scheduling/authentication/refused"}Headers
Section titled “Headers”Bearer authentication challenge.
Every answer is marked no-store, so a booking view is never served from a cache.
W3C trace context for the request and response.
Problem response: profile.not-authorized
object
Example
{ "code": "profile.not-authorized", "detail": "The selected Scheduling profile does not authorize this request.", "status": 403, "title": "Profile not authorized", "type": "https://id.registrystack.org/problems/registry-scheduling/profile/not-authorized"}Headers
Section titled “Headers”Every answer is marked no-store, so a booking view is never served from a cache.
W3C trace context for the request and response.
Problem response: request.method-not-allowed
object
Example
{ "code": "request.method-not-allowed", "detail": "The route exists but not for this method.", "status": 405, "title": "Method not allowed", "type": "https://id.registrystack.org/problems/registry-scheduling/request/method-not-allowed"}Headers
Section titled “Headers”Every answer is marked no-store, so a booking view is never served from a cache.
W3C trace context for the request and response.
Problem response: request.body-too-large
object
Example
{ "code": "request.body-too-large", "detail": "The request body exceeds the accepted size.", "status": 413, "title": "Payload too large", "type": "https://id.registrystack.org/problems/registry-scheduling/request/body-too-large"}Headers
Section titled “Headers”Every answer is marked no-store, so a booking view is never served from a cache.
W3C trace context for the request and response.
Problem response: service.unavailable
object
Example
{ "code": "service.unavailable", "detail": "Scheduling storage is unavailable. Try again after the service recovers.", "status": 503, "title": "Scheduling service unavailable", "type": "https://id.registrystack.org/problems/registry-scheduling/service/unavailable"}Headers
Section titled “Headers”Seconds before retrying the unavailable dependency; the runtime answers 5.
Every answer is marked no-store, so a booking view is never served from a cache.
W3C trace context for the request and response.