---
title: "Get Bootstrap"
method: GET
path: "/v1/bootstrap"
tags: ["bootstrap"]
---

# Get Bootstrap

`GET /v1/bootstrap`

Return the deployment context the dashboard shell renders from.

Public: the shell fetches this before it knows whether it can authenticate.
That is also why ``sign_in_methods`` is answered here rather than behind a
credential, and it publishes nothing an unauthenticated caller could not
already learn by trying both credentials against the sign-in endpoint.

The one database read is a ``LIMIT 1`` probe for any identity holding a
password, over a table a standalone deployment keeps one row per person in.
It runs only in standalone mode: a hybrid gateway has no session to describe,
and ``get_db_if_needed`` hands it no session to read one from.

## Response `200`

Successful Response

- DeploymentBootstrap — What the dashboard shell needs before it can render anything.
  - `deployment_type` 'standalone' | 'hosted' | 'hybrid', required — Which deployment serves this URL. 'standalone' owns its own data; 'hosted' is otari.ai; 'hybrid' is a gateway attached to otari.ai, which is data-plane only and holds no management surface of its own.
  - `mail_ready` boolean, required — Whether this deployment can deliver a message carrying a link back to itself (an invitation's accept link, and the verification and reset links to come), not merely whether a transport is configured: it also needs to know its own public URL to put in one. Lets the dashboard disable or hide a mail-dependent affordance instead of offering one that would fail at send time. Every message this control plane sends carries such a link, which is why this is one flag and not one per feature. False for a hybrid gateway, whose control plane is otari.ai and which sends no mail of its own.
  - `management_url` string, nullable, required — Where the authoritative control plane lives when it is not this deployment. Set for a hybrid gateway so its landing page can link to otari.ai; null otherwise.
  - `session_type` 'local_operator' | 'hosted_user' | 'none', required — The kind of session this deployment issues, not whether the caller holds one. 'local_operator' is the standalone operator sign-in (see sign_in_methods for which credential it currently accepts), 'hosted_user' an otari.ai account, and 'none' a deployment that issues no management session at all.
  - `sign_in_methods` string[], required — How POST /v1/auth/session may be authenticated right now, sorted. 'master_key' is the first-boot credential and is offered until some identity on this deployment has a password; 'password' replaces it from then on, and the master key stays the credential for the management API. Empty for a hybrid gateway, which issues no session. The login page renders from this rather than trying a credential to find out.
  - `surfaces` string[], required — Management API groups this deployment serves, sorted, which is what its dashboard pages gate on. Named surfaces, not capabilities: capability is otari.ai's word for the entitlement (licensing) axis, and this is the deployment (topology) axis. Empty for a hybrid gateway.

---

[API](https://skmtc.net/mozilla-ai/apis/otari.md) · [All operations](https://skmtc.net/mozilla-ai/apis/otari/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/mozilla-ai/otari/revisions/9c654bb5b126/schema)