Check readiness with whoami

September 13, 2026API

From a 200 on a sandbox call there was no way to know whether a production call would work. The first signal was a 403 in production. GET /v1/whoami answers the question up front.

The endpoint

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

200 OK
{
  "app": { "id": "lyt_app_3f9c0d2e7a41b65c08e9d1f2" },
  "environment": "sandbox",
  "approvalStatus": "pending",
  "scopes": ["order:preview", "order:build", "order:status", "order_status", "places"]
}

environment is decided by the key's prefix.
approvalStatus is the application's real status, so a sandbox key on an unapproved application answers pending. That is the thing to check before you switch keys.
scopes is what a build grant from this application may do, so you can code against the boundary instead of discovering it at a tool call.

It reads nothing beyond the key itself, so it is safe to call from a deploy script.

Production stays sealed until approval

A new application's production secret is not handed out until the application is approved. Sandbox credentials are available immediately.
Before approval, revealing or rotating the production secret answers not_approved.
When your application is approved, you get an email saying so.

What to do

Add a whoami check to the step that switches you to production, and fail the deploy unless it answers approved:

curl -s https://api.layout.link/v1/whoami -H "Authorization: Bearer $LAYOUT_SECRET" \
  | jq -e '.approvalStatus == "approved"' > /dev/null || exit 1

Breaking changes

None. Production was already refused before approval; this only says so sooner.

All changes