Skip to content
API · Authentication

OAuth · client_credentials.

Server-to-server only. UAMKT does not run a user-facing sign-in flow against Lattice — every authentication is between our publishing service and the partner's sandbox.

StableOAuth · RFC 6749 §4.4

Five-step flow.

  1. 01Provision sandbox

    Anduril Developer Zone is the source of truth. Each partner gets a per-tenant sandbox (current UAMKT sandbox: 30dhgc, token expiry 2026-06-03).

  2. 02Issue client credentials

    Partner BD team receives a `client_id` + `client_secret` pair. Stored in Vercel env, never committed.

  3. 03Token exchange

    Server-side OAuth `client_credentials` grant. Tokens are short-lived (~1 hour); rotate by re-exchanging.

  4. 04Bearer attach

    Bearer token attached on every PUT /api/v1/entities call. 401 means refresh.

  5. 05Audit

    Every token exchange and every entity submit is logged in the partner sandbox and replayable from the Developer Zone console.

Token exchange.

Request
POST https://developer.anduril.com/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=<sandbox-client-id>
&client_secret=<sandbox-secret>
&scope=lattice.entities.publish
Response
HTTP/1.1 200 OK
{
  "access_token": "eyJhbGc...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "lattice.entities.publish"
}

Environment variables.

Three secrets in production. None are committed; all are set in Vercel project settings.

  1. LATTICE_OAUTH_CLIENT_ID

    Provided by Anduril Developer Zone per sandbox. Server-side only.

  2. LATTICE_OAUTH_CLIENT_SECRET

    Server-side secret. Vercel env. Rotated by Anduril on partner request.

  3. LATTICE_API_BASE_URL

    Sandbox-specific API base. Currently 30dhgc; production base assigned per partner.

Continue

Lattice Publish API →← API overviewRequest sandbox