API tokens

If your status already lives somewhere else — a deployment pipeline, a data warehouse, an internal tool — you can push updates into StatusLoop rather than asking someone to retype them. An API token authenticates that.

Creating a token

1. 1Go to Admin → Overview → API tokens.
2. 2Give the token a name describing where it will be used, not what it does — “deploy pipeline”, not “updates token”. When you come to revoke one, you will want to know what breaks.
3. 3Optionally set an expiry in days. A token that expires is one you cannot forget about.
4. 4Create it, and copy the value immediately.

Using it

Send the token as a bearer credential against the updates endpoint. Tokens begin with a recognisable prefix, which makes them easy to spot in a secret scanner.

• •Authorization: Bearer sl_live_…
• •POST to /api/v1/updates with a JSON body identifying the project and the status being reported.
• •A malformed body returns 400; an unknown project returns 404; a cycle that is already closed returns 409.

Rate limits

Two limits apply. Each token is capped per minute, and each source address is capped separately and more loosely, because one address may legitimately run several integrations. The address limit is checked first, so a client guessing at tokens is stopped before it costs a database lookup.

Exceeding a limit returns 429 with a Retry-After header — honour it rather than retrying immediately. If the limiter itself is unavailable the endpoint returns 503, also with Retry-After. It fails closed on purpose: a rate limiter you can bypass by causing an error is not a rate limiter.

Revoking

Revoke from the same screen. It takes effect immediately. Revoke whenever someone who had access leaves, when a token has been pasted somewhere it should not have been, or when you no longer recognise what an integration is for.