Person credentials for the API

October 1, 2026API

Your client secret acts as your application. The REST API can now also be called with a credential that acts for one person.

What changed

A new OAuth resource. Authorize with resource=https://api.layout.link to get an access token for the REST API. Only an OAuth client your application created in the console can ask for it. Tokens for https://mcp.layout.link are unchanged and are not accepted by the API.
Neither one adds a card. A build grant can never add a card or spend, and cannot confirm a production order.
Build grants work on the API. An lgb_ grant authenticates the same build session it does over MCP.
A disconnect is immediate. When a person disconnects your app, their access token is refused on the next request.
GET /v1/whoami answers for both. It returns kind ("user" or "grant"), the application, the environment and the person's user.id. Called with your secret it now also returns "kind": "app".

curl https://api.layout.link/v1/whoami \
  -H "Authorization: Bearer $ACCESS_TOKEN"

200 OK

{
  "kind": "user",
  "app": { "id": "lyt_app_3f9c2a7e1b4d8f6a0c5e9b27" },
  "environment": "live",
  "user": { "id": "usr_4b8e" },
  "scopes": ["order"]
}

Why it matters

The same two ways in that MCP has, a person who signed in and a person you provisioned, now reach the REST API. You can check a token end to end with GET /v1/whoami before you call anything else with it.

What to do

Nothing, unless you want to try it. See Calling the API as a person.

Breaking changes

None. GET /v1/whoami with your secret returns one new field, kind, and nothing else about it changed.

All changes