API keys

An API key is how your own code and your agents act on a Lanes workspace, without a browser session and without a person in the loop.

A key is issued against a workspace, and what it may reach there is a matter of scope. This page covers the key itself: what one is, how you manage it, and what it can and cannot do. Each product then documents the scope it grants, and Forms is the scope available today.

What a key is

Keys are prefixed lfk_ followed by a random secret.
They are workspace-scoped, not per-product and not per-resource. One key covers its workspace.
Only the sha256 hash and a short display prefix (for example lfk_a1b2c3d4) are stored. The full key is shown once at creation and can never be retrieved again.

Create, list and revoke a key

Keys are created and revoked in the dashboard, under API keys. All three endpoints require a signed-in owner of the workspace.

Method	Path	Result
`POST`	`/v1/workspaces/{workspace_id}/api-keys`	`201`, returns the plaintext `key` once. Max 10 active keys, then `429 api_key_limit_reached`.
`GET`	`/v1/workspaces/{workspace_id}/api-keys`	Lists keys (display prefix only, never the secret or hash). Revoked keys included.
`DELETE`	`/v1/workspaces/{workspace_id}/api-keys/{key_id}`	`204`. Soft-revokes the key; the row is kept for audit.

Copy it now

The plaintext key appears exactly once, at creation. Store it in your secret manager immediately. If you lose it, revoke it and create a new one.

Send a key with a request

Send it as a bearer token:

Bash

curl https://api.lanes.sh/v1/forms \
  -H "Authorization: Bearer lfk_..." \
  -H "Content-Type: application/json" \
  -d '{"name":"Contact","schema":[{"name":"email","type":"email","required":true}]}'

Unknown and revoked keys both return the same 401 invalid_api_key, so a probe cannot tell a wrong key from a revoked one.

What a key can reach

What a key reaches is decided per product. Lanes Forms is the one scope a key carries today; anything not listed below is not reachable with a key.

Forms

A key in the Forms scope does three things:

Provision pre-claimed forms. Send Authorization: Bearer lfk_... on POST /v1/forms and the form is born claimed in the key's workspace, skipping the claim step entirely. See Provisioning.
Manage forms. GET and PATCH /v1/forms/{form_id} and resend-verification accept the workspace key in place of a signed-in owner. Management applies to claimed forms only.
Submit server-side. For a form in api_key submission mode, server-side requests must carry the key. See Securing your endpoints.

What a key cannot do

Keys do not authorize dashboard reads (listing submissions, workspaces, projects). Those use your signed-in session.
There is no per-resource secret. The workspace key, or a signed-in owner, is the only programmatic path.
A key carries no scope it was not granted. A key is not a way around a permission a person does not have either: creating and revoking keys is owner-only.

Server-side only

An lfk_ key is a secret. Never embed it in a browser bundle, a mobile app, or any client a user can inspect. Browser forms are secured by origin, not by keys. See Securing your endpoints.

Next: Securing your endpoints.