Authentication

Every request carries a project API token as a bearer token:

GET /v1/releases HTTP/1.1
Host: api-public.localeo.app
Authorization: Bearer localeo_9fK2xY7pQ3mNvB8sL1tR4wZ6cD0aJ5hG2eU7iO9k

There is no other authentication scheme. No cookies, no OAuth flow, no signed requests.

The token

A token is a localeo_ prefix followed by 40 random characters. The prefix is there so a leaked token is recognisable on sight — in a log, a bug report, or a scanning tool.

Tokens are created in the dashboard under Project → API tokens, and the full value is returned exactly once, at creation. Localeo stores only a SHA-256 hash of it, so a lost token cannot be recovered — it can only be deleted and replaced. The dashboard shows the first 14 characters (localeo_9fK2xY) so you can tell tokens apart without exposing them.

Scope

A token belongs to one project, and reads only that project. This is why no endpoint takes a project ID: the token already determines it, and GET /projects returns a single-element list rather than a directory of everything you can see.

The practical consequence is that a token is a poor secret to share between systems. If two services need access, give them two tokens, so either can be revoked without disrupting the other.

Failure modes

Both authentication failures return 401 with the standard error shape:

Situation	Response body
No Authorization header, or one not starting with Bearer	{"error": "missing bearer token"}
Header present but the token is unknown, revoked, or malformed	{"error": "invalid token"}

Failed requests still consume rate limit

The rate limiter runs before authentication, so a 401 costs quota exactly like a successful request. A retry loop against a bad token will exhaust the hourly allowance and start receiving 429 instead — which looks like a rate-limit problem but is really an auth problem. See Rate limits.

Revoking a token

Delete it in the dashboard. It stops working immediately for anything that reaches authentication — but see the caveat below.

Revocation is not instant for repeated requests

Successful responses are cached for 60 seconds, keyed on the token and the URL. A request that exactly matches a cached one is served from that cache without reaching authentication, so a revoked token can keep receiving responses for up to a minute after deletion.

This matters when you revoke in response to a leak. Rotating the affected release’s public slug is what actually cuts off access to the bundle files; revoking the token closes the metadata API a minute later. Caching explains the mechanism.

Keeping tokens out of the wrong places

The bundle download URLs carry no credentials, so the token is only ever needed for the four metadata endpoints. In practice that means it belongs on a server or in a CI environment, and rarely in a shipped client.

If you do embed a token in a distributed application, understand what it grants: read access to that project’s release metadata and to every download URL. It cannot modify anything, but the URLs it reveals are themselves unauthenticated and non-expiring — see Releases & bundles.