What this is: an API key lets a program read your Admaxxer analytics the same way you read them in the dashboard — but without a browser or a login. If you want your own script, spreadsheet, internal tool, or AI assistant to pull your numbers on a schedule, a key is how you give it permission. If you only ever look at your data in the dashboard, you don’t need one.
Looker Studio, nightly-export, claude-assistant.The name is only for you — it’s how you’ll recognise the key in the list later. Name it after the single tool or script that will hold it, so that revoking it one day is an easy decision.
Tick only the permissions the tool actually needs (see the table below). If you’re not sure, start with read access only — a read-only key can never change your data. If you don’t choose anything, the key is created with pixel:read only.
wk_.We cannot recover this for you. We keep only a fingerprint of your key — enough to check that a key you send us is valid, never enough to reconstruct it. If you close the dialog without copying, revoke the key and create another. It takes ten seconds and costs you nothing.
Send the key on every request in an Authorization header. Treat it like a password: anyone holding it can do whatever you allowed it to do, so keep it out of shared docs, screenshots, and anything you commit to a code repository.
Each permission is a switch you tick when creating the key. Tick only what the tool needs — you can’t change them afterwards, and a key that can only read is a key that can never break anything.
| Permission | What it’s called | Access | What it allows |
|---|---|---|---|
pixel:read | Read analytics (default) | Read only | View visitors, pageviews, goals, alerts, reports, and share links. |
pixel:write | Write analytics | Can change data | Create and update goals, alerts, scheduled reports, and share links. |
Every request carries the key in an Authorization header, in the form Bearer <your key>. Swap the placeholder below for your real key.
Ask Admaxxer what it thinks your key is. This is the fastest way to confirm you copied it correctly and to see which permissions it actually carries.
curl https://admaxxer.com/api/v1/me \
-H "Authorization: Bearer wk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
A working key answers with its own name, its permissions, and the workspace it belongs to:
{
"apiKey": {
"id": "…",
"name": "nightly-export",
"scopes": ["pixel:read"]
},
"workspace": { "id": "…" }
}
Check the scopes list here first whenever something is refused — it tells you exactly what this key is allowed to do.
pixel:read)curl "https://admaxxer.com/api/v1/pixel/segments?website_id=YOUR_WEBSITE_ID" \
-H "Authorization: Bearer wk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
pixel:write)curl -X POST https://admaxxer.com/api/v1/pixel/segments \
-H "Authorization: Bearer wk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{
"website_id": "YOUR_WEBSITE_ID",
"name": "Paid visitors",
"filters": {}
}'
A key without write access will refuse this — see below.
Your key is valid, but it wasn’t given this particular permission when it was created. The response tells you both halves of the problem — what was needed, and what your key actually has:
{
"error": {
"code": "insufficient_scope",
"message": "This endpoint requires the 'pixel:write' scope",
"details": {
"required": "pixel:write",
"available": ["pixel:read"]
}
}
}
The fix: permissions can’t be added to an existing key, so create a new key with the permission listed under required ticked, swap it into your tool, then revoke the old one.
The key is missing, mistyped, or revoked. Check that the header reads Authorization: Bearer wk_… — the word Bearer and the space after it are both required. A stray quote, newline, or truncated paste is the usual culprit.
You’re calling faster than the allowance. Wait for the interval given in the Retry-After header and try again. If you’re pulling a lot of data on a schedule, spread it out rather than bursting.
There’s no recovery step, and that’s the point — because we never hold your key, nobody can be talked into handing it over. Losing one is a two-minute inconvenience, not an incident:
If a key may have been exposed — pasted into a shared document, a screenshot, or a public code repository — revoke it first and ask questions afterwards. A revoked key is worthless to whoever found it.
Q: I closed the dialog without copying my key. Can I get it back?
No — and that’s a security property rather than a gap. We only ever keep a fingerprint of your key, so there is no copy of it anywhere for us or for support to look up. Revoke the key you lost and create a new one; it takes about ten seconds.
Q: The copy button didn’t seem to do anything. What now?
Copy puts the key on your clipboard without any visible change to the page, so it can look like nothing happened. Paste into a text field to check. If it really is empty, close the dialog, revoke that key, and create a fresh one — never keep working with a key you couldn’t copy.
Q: Can I change a key’s permissions later?
No. Permissions are fixed when the key is created, so a key can never quietly gain access it didn’t have on day one. To change what a key can do, revoke it and issue a new one with the permissions you want.
Q: Do API keys expire?
No. A key works until you revoke it. Good practice is to give each tool its own key and revoke it when that tool is retired, so an unused key never lingers.
Q: How many keys can I create?
As many as you like. One key per tool is the pattern we recommend — it’s the only way to retire one integration without disturbing the others.
Q: Is a key tied to my login?
A key belongs to the workspace, not to you personally. It keeps working if you change your own password, and revoking it doesn’t affect anyone’s ability to log in.
Settings — API Keys · Connect an AI assistant · Developer reference · Documentation home