Authentication

One bearer token on every request. The client secret is the identity: there is no session, no cookie, and no token exchange to implement.

Authorize every request

Send the client secret as a bearer token. Layout reads it from the Authorization header and nowhere else, so a secret in a query string or a cookie is simply ignored.

curl https://api.layout.link/v1/users \
  -H "Authorization: Bearer $LAYOUT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{ "firstName": "Dana", "lastName": "Whitfield", "phone": "+19165550142" }'

What the console gives you

CredentialShapeNotes
Client idlp_test_… / lp_live_…Identifies the application. Not a secret, but not useful on its own.
Client secretsk_test_… / sk_live_…The credential. Shown once at creation. Layout stores only a hash and the last four characters.
Webhook signing secretOn the Webhooks pageDifferent secret, different job. See Webhooks.

The prefix selects the environment. A sk_test_ secret can only ever reach sandbox, whatever else the request says.

Keep the secret server-side. It provisions users and starts orders, so anything holding it can act as your application. Never ship it in a browser bundle or an app binary.

Rotating a secret

Rotate from the application's Credentials page. Rotation is immediate and there is no overlap window: the moment the new secret is issued, the old one is refused. Deploy the new secret first and rotate second, or take the brief gap deliberately.

Revealing or rotating a production secret asks you to sign in again if your session is older than fifteen minutes. A stolen browser session should not be enough to walk away with a live credential.

A request made with a rotated secret is refused with 401. The response body is the same as every other refusal, so a rotation that took your fleet by surprise looks identical to a bad key. The console's Refusals page is where the two are told apart: a rotated key shows as credential_revoked.

Two tokens that are not this one

TokenWhat it is
lgb_…A build grant, returned when you provision a user. It authenticates a build-only session for that one person and can never add a card, confirm, or spend.
MCP OAuthMCP clients register dynamically and use PKCE. No client secret lives in the assistant. See Ordering over MCP.

When a call is refused

Every refusal returns the same body with either 401 or 403:

  • 401 — the secret was not recognised, was malformed, or has been rotated.
  • 403 — the secret is real, and this application is not permitted to do that. Almost always production access on an application that is not approved.

The body never says which. Read the reason on the application's Refusals page in the console.

Next
Provisioning users →