A valid request URL is required to generate request examples{
"resource": "<string>",
"authorization_servers": [
"<string>"
],
"bearer_methods_supported": [
"<string>"
],
"scopes_supported": [
"devices:read"
],
"resource_documentation": "<string>"
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}Discover where to authenticate, at the endpoint suffixed path
The same document as the unsuffixed path, byte for byte. Both exist because clients try both, and the bearer challenge points at this one.
Hosted deployments only. A local checkout does not mount this route, so calling it there is a 404.
A valid request URL is required to generate request examples{
"resource": "<string>",
"authorization_servers": [
"<string>"
],
"bearer_methods_supported": [
"<string>"
],
"scopes_supported": [
"devices:read"
],
"resource_documentation": "<string>"
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}Response
The metadata document.
RFC 9728 protected resource metadata.
The resource identifier your token must be audienced to (RFC 8707).
Issuer urls of the authorization servers this resource advertises for discovery. Optional, as RFC 9728 section 2 allows: a deployment may choose not to advertise some or all of the authorization servers it accepts. When it advertises none, the field is absent rather than an empty array, and the client is told where to authenticate out of band.
The scopes an authorization server may grant for this resource.
A scope name from the one vocabulary both credential channels use.
devices:read, devices:act, devices:lease, runs:start, orders:place, apps:read, apps:write, apps:delete