Browse the docs

API reference

Authentication

Latido has three kinds of credentials. Each surface accepts exactly one family, and the prefix tells them apart.

Credential Looks like Used on Get it
Project API key lat_test_<32 base62> / lat_live_<32 base62> Public API /v1/*, MCP /mcp (data tools) Sign-up (one test key), or dashboard → project → API keys
Personal MCP token lat_mcp_… MCP /mcp (user tools only) Dashboard → Settings → Agents (MCP)
Session JWT a JWT (HS256, 8 h) Dashboard API /dashboard/*, /mcp-tokens POST /auth/login or POST /auth/sign-up

All three go in the same header:

Authorization: Bearer lat_test_…

API keys

  • Scoped to one project and one mode. The request's project and mode come from the key alone — never from the URL or the body. A key cannot read another project's members.
  • Test vs live. A lat_test_ key sees only test members and can only connect the demo provider (latido_demo); a lat_live_ key never sees the demo provider. Members, connections, records, events and webhook endpoints all carry the mode they were born in, so the two worlds never mix. Test members do not count towards the plan's connected-members limit; uploads through the ingest endpoint need a live key.
  • Shown once. Latido stores only the SHA-256 of the key (plus a 12-character display prefix such as lat_live_4fK). Lose it and create another.
  • Revocation is immediate: dashboard → API keys → Revoke (POST /dashboard/projects/{projectId}/api-keys/{apiKeyId}/revoke). A revoked key answers 401 like an unknown one.
  • Metering. Every authenticated /v1 and /mcp request counts towards the account's monthly request quota; see errors-and-limits.md.
  • Keep keys on your server. The connect flow is designed so the browser never needs one: your backend creates the connect session and hands the user its url.
ts
import { Latido } from "@latido/sdk";
const latido = new Latido({ apiKey: process.env.LATIDO_API_KEY! });
latido.mode; // "test" | "live", from the prefix

The SDK refuses anything that is not lat_test_… / lat_live_… at construction time.

The 401

A missing, malformed, unknown or revoked credential gets:

http
HTTP/1.1 401 Unauthorized
Content-Type: application/json

{ "errorCode": "UNAUTHORIZED", "message": "Unauthorized" }

There is deliberately no WWW-Authenticate header (on /v1 and /mcp): a bearer key is the only scheme, and advertising one sends some MCP clients into OAuth discovery.

Dashboard sessions

POST /auth/login ({ email, password }) or POST /auth/sign-up ({ email, password (≥ 10 chars), name, accountName, appsumoLicenseToken? }) return data.token, a JWT valid for 8 hours. It authorizes the dashboard API: projects, API keys, provider apps, webhook endpoints, the event log, usage and billing. It is not accepted on /v1 or /mcp.

MCP tokens

Personal tokens (lat_mcp_…) act as the dashboard user who created them; they are minted and revoked only with a session (/mcp-tokens), so a leaked token cannot mint its replacement. For reading health data from an agent, use a project API key on /mcp instead — see mcp.md.

Webhook secrets

Outgoing webhooks are not authenticated with a key: each endpoint has its own signing secret (whsec_<32 base62>, shown once at creation or rotation). See webhooks.md.