# Authentication

Availability: Release contract.
Last reviewed: 2026-08-28.

Human sign-in and application authentication solve different problems. Human sessions authorize console administration; application keys identify an account-owned application and its permitted API scope.

## Authenticate a request

The release contract accepts an application key in the `X-Market-Monolith-Key` header for `GET /v1/me`. Use HTTPS and a trusted server-side client. The key must not appear in a query parameter, browser storage or a client-side script.

The result identifies the credential’s account and application. “Me” does not mean the signed-in person. A browser login cookie is not a replacement for an API key.

## Developer sessions

The developer portal uses a separate host-only session. Signing in or out there does not sign you in or out of the main site. Ordinary console reads remain available until the seven-day absolute limit or twelve-hour idle limit is reached.

Sensitive actions—including account/application/key creation, renaming, replacement and revocation—require email proof from the last fifteen minutes. When that proof expires, reverify to continue the intended action. Starting or failing step-up does not destroy the still-valid ordinary session. A successful step-up rotates the session credential without extending its absolute lifetime.

## Current authority still matters

Every private operation must retain current account and membership authorization. A valid session or recent proof cannot restore a revoked role, suspended account or unavailable authority check.

## Keep API scope narrow

New developer keys carry `identity:read` only. Research, territory changes, campaign work, credits and providers are not enabled. A revoked or replaced key stops authenticating.

Do not automatically replace a key after a network error. Check safe metadata and the request destination first. See [Permissions](/docs/permissions) and [API-key lifecycle](/docs/api-keys).