API keys
An API key lets something that is not a browser act for one of your sites: a server sending events, a deploy pipeline writing a note, an agent reading your numbers.
The tracking snippet needs no key. It is public by design, and a secret inside a public script would not be a secret. Keys are for the other paths.
Creating one
Settings → API keys. Give it a name you will recognise later, choose what it may do, and create it. The key is shown once, on that screen, and never again: only a hash of it is stored, so a copy of the database is not a set of working keys. If you lose one, revoke it and make another.
A key belongs to one site. It cannot read or write any other site, even one in the same account.
Scopes
Choose the least the caller needs.
| Scope | What it allows |
|---|---|
| Send events from a server | Report crawler hits from your server |
| Write notes on charts | Pin a note from a deploy pipeline or an agent |
| Read this site’s analytics | Ask the numbers behind every screen over MCP |
Scopes are fixed when the key is created. To change them, revoke the key and create another; that way a key’s powers never quietly grow.
Using one
Send it as a bearer token:
curl -H "Authorization: Bearer lynq_sk_…" https://lynq.byharsh.com/…A key may make 120 requests a minute across every endpoint; the 121st gets 429 until the minute turns. Batch where the endpoint allows it. A key is refused on a request that carries a browser origin for the site, so a key that leaks into front-end code cannot be replayed from a page. Treat it like a password: keep it in your deployment’s secrets, never in a repository.
Revoking
Settings → API keys → Revoke. It stops working immediately. The row is kept, without the key, so you can still see that it existed and when it was last used.