Authentication

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 and API-key lifecycle.