Explain one start's refusal
const url = 'https://scheduling.example.test/v1/availability/explain?offering=example&start=2026-04-15T12%3A00%3A00Z';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/availability/explain?offering=example&start=2026-04-15T12%3A00%3A00Z' \ --header 'Authorization: Bearer <token>'The separately authorized explanation of one start under the same optional durationMinutes and resource constraints as availability: the problem code every caller may see, the detailed code only this path discloses, and the refusal in words. A start that admits as things stand answers with no codes at all. The probe is a minimal party, so the answer explains the calendar and the capacity, never another caller’s booking. resource.unavailable is disclosed here and never on the public path, whose answer is capacity.exhausted.
Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Header Parameters
Section titled “Header Parameters”Optional W3C trace context continued in the response.
Query Parameters
Section titled “Query Parameters”Required offering identifier. An offering the deployed policy does not publish is request.not-found.
The start to explain.
Requested exact-time service duration in minutes. It is a hard constraint and must satisfy the offering’s published duration selection policy.
Requested exact resource identifier. It is a hard constraint and is accepted only when the offering permits resource selection.
Responses
Section titled “Responses”Success
object
Example generated
{ "detailedCode": "example", "explanation": "example", "offering": "example", "publicCode": "example", "start": "2026-04-15T12:00:00Z"}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.invalid
object
Example
{ "code": "request.invalid", "detail": "The request could not be read as a Scheduling request.", "status": 400, "title": "Request invalid", "type": "https://id.registrystack.org/problems/registry-scheduling/request/invalid"}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.not-found
object
Example
{ "code": "request.not-found", "detail": "The requested route does not exist.", "status": 404, "title": "Route not found", "type": "https://id.registrystack.org/problems/registry-scheduling/request/not-found"}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.