Change the Namespace's settings
const url = 'https://app.caprid.com/v1/account';const options = { method: 'PATCH', headers: {Authorization: 'Bearer <token>', 'Content-Type': 'application/json'}, body: '{"platform_peering":true}'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request PATCH \ --url https://app.caprid.com/v1/account \ --header 'Authorization: Bearer <token>' \ --header 'Content-Type: application/json' \ --data '{ "platform_peering": true }'PATCH /v1/namespaces/{namespace} for the API key’s only Namespace, answered with the caller.
Authorizations
Section titled “Authorizations”Request Bodyrequired
Section titled “Request Bodyrequired”object
Whether the Namespace’s tracks may travel between your Self-hosted relays and Platform relays, the relays Mux runs. A change takes effect within about a minute. Your Regions can’t link to Mux’s yet, so for now this changes nothing.
Example generated
{ "platform_peering": true}Responses
Section titled “Responses”The caller, with the change applied.
object
object
The person signed in. Absent for an API key.
When the person signed up. Absent for an API key.
The API key making the call, with its namespaces limit if it
has one. A limited key can’t list its Organization’s Namespaces,
so this is how it finds the ones it can reach. Absent for a
session.
object
Identifies the key for revoking it. Not a secret.
The first 6 characters of the secret after sb_, so you can tell keys apart.
Absent for a key that never expires.
Absent for a key that has never been used.
The Namespaces the key is limited to, by name. Absent for a key
with no limit. A deleted Namespace drops out, so a key whose
Namespaces have all been deleted has [] here and can do nothing.
A customer of Switchboard. It owns its Namespaces, and the API keys, Nodes and enrollments that serve them. Its Members manage all of it.
object
Identifies the Organization in routes. It never changes.
For display. Any Member can change it.
Your role in it. Absent for an API key, which has none.
When a Trial Organization lapses, so its Agent knows how long it has to get a person to claim it. Absent for every other Organization.
The one Namespace you can reach, as this reported before Organizations. Absent unless you reach exactly one.
That Namespace’s platform_peering. Absent along with namespace.
Example
{ "account": { "api_key": { "id": "3f9a1c07be42", "namespaces": [ "acme-staging" ] }, "organizations": [ { "id": 4, "name": "Acme", "role": "owner", "trial_expires_at": 1760604800 } ], "namespace": "acme" }}Sent with a session, or with an API key that doesn’t reach exactly one Namespace. Use the route the message names instead. This route also returns 400 for anything that route would refuse with 400.
object
Example
{ "error": "this API key reaches 2 Namespaces, so this route can't tell which one you mean; use /v1/namespaces/{namespace}/keys"}No valid credential. Missing, expired and revoked credentials all get the same response, and so does an API key whose trial has lapsed. An Agent token from before a claim gets a 401 too, once the claim has made the trial a person’s, with a message saying to get a new token.
object
Example
{ "error": "the requested grants exceed the key's scope"}Headers
Section titled “Headers”Example
Bearer realm="switchboard"Sent with an API key limited to some Namespaces, to a Namespace outside its limit, or to a route that acts on the Organization as a whole. A limited key can never create API keys.
object
Example
{ "error": "this API key is limited to the Namespaces acme-staging, and acme isn't one of them"}