Skip to main content
Every request to the API requires a Bearer token in the Authorization header.
lmp_test_ keys are not sandboxed. The prefix is a label for your own bookkeeping — nothing more. A lmp_test_… key has identical permissions to a lmp_live_… key: it publishes to your real connected accounts and burns real quota. Sandbox isolation is on the roadmap; until it ships, do not point an integration test suite at a test key expecting it to be inert.

​
Headers

The dashboard’s API keys page mints, lists, and revokes keys. The secret is shown exactly once — at create time. After that, rotate to replace it.

​
Key shape

Both rows are identical on purpose — that is the current behaviour. The prefix is chosen at mint time and stored on the key so you can tell two keys apart in the dashboard; the API does not branch on it. There is no separate sandbox base URL, no sandbox account pool, and no write rejection for test keys. The hash, not the secret, is stored at rest. Your secret is unrecoverable after creation.

​
Scoping

A key carries two scopes:
  • Organization — every key is bound to a single organization. There is no cross-org key.
  • Profile (optional) — a key may be pinned to a single profile within the org. Cross-profile access by a profile-scoped key returns 404 not_found, never 403, so the key cannot probe for the existence of other profiles.
Set the profile scope at creation time. To widen scope, mint a new key — keys are immutable.

​
Read vs write

Read endpoints (GET /v1/posts, GET /v1/posts/:id, GET /v1/media, GET /v1/accounts) accept either a Bearer key or a dashboard session cookie. Writes accept Bearer keys only.

​
Rotation

There is no automatic key rotation. To rotate:
  1. Mint a new key in the dashboard.
  2. Switch your application secret to the new key.
  3. Revoke the old key.
Revocation is immediate; in-flight requests on the old key fail with unauthenticated.

​
OAuth tokens are different

The Authorization: Bearer … header authenticates you to letmepost. The OAuth tokens we hold for upstream platforms (Bluesky session, LinkedIn access token, etc.) are managed entirely server-side, AES-256-GCM encrypted at rest, and refreshed on the platform’s schedule. You never see them. See accounts for the connection lifecycle.

​
Errors