---
title: "Create Session"
method: POST
path: "/v1/auth/session"
tags: ["auth"]
---

# Create Session

`POST /v1/auth/session`

Verify the master key and set the HttpOnly session cookie.

The session is bound to the bootstrap operator identity, so every request it
later authenticates resolves a user and that user's active organization
rather than only "the master key was presented once". The response names
both, so a client knows who it is signed in as without a second call.

The rate-limit check deliberately runs only after a failed verification,
not before it: a pre-verification gate can't know whether *this* attempt
would have succeeded, so once an IP has used up its failure quota it
would end up blocking that IP's legitimate owner too, not just further
attackers. The issue this implements explicitly rules that out. The
DB/hash lookup this exposes to repeated attempts only runs when no fixed
master_key is configured (the auto-generated bootstrap-key path); with a
configured master_key, verification is a constant-time string compare,
not a DB round trip.

## Request body

- CreateSessionRequest — Sign in to the dashboard by proving possession of the master key.
  - `master_key` string, required — The gateway master key; verified once and never stored by the browser.

## Response `200`

Successful Response

- SessionResponse — A freshly minted dashboard session (the token travels only in the cookie).
  - `active_organization_id` string, uuid, required — The organization that identity is acting in, which scopes every tenancy surface.
  - `expires_at` string, date-time, required — When the session cookie stops being accepted.
  - `user_id` string, uuid, required — The identity this session speaks for.

## Other responses

- `422` — Validation Error

---

[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/2ebadef75cc8/schema)