The Admaxxer Pixel API is a small, opinionated REST surface that exposes the same analytics data powering the in-app dashboards. Everything is scoped to a single workspace by API key — there are no account-wide superuser endpoints.
https://admaxxer.com/api/v1/1. Create an API key in Settings › API Keys with the pixel:read scope. Copy the value — it is shown exactly once.
2. Verify the key works:
curl https://admaxxer.com/api/v1/me \
-H 'Authorization: Bearer YOUR_KEY'3. List your pixel websites:
curl https://admaxxer.com/api/v1/pixel/websites \
-H 'Authorization: Bearer YOUR_KEY'4. Query realtime visitors. The endpoint server-side-proxies our analytics warehouse and returns the pipe rows directly:
curl 'https://admaxxer.com/api/v1/pixel/metrics/the live-visitors feed?website_id=admx_123' \
-H 'Authorization: Bearer YOUR_KEY'
# → { "status": "success", "data": { "data": [...rows], "meta": [...], "rows": N, "statistics": {...}, "data_status": "ok" }, "meta": { "request_id": "..." } }5. Ship a server-to-server event (requires pixel:write):
curl -X POST https://admaxxer.com/api/v1/pixel/events \
-H 'Authorization: Bearer YOUR_KEY' \
-H 'Content-Type: application/json' \
-d '{"website_id":"admx_123","name":"pageview","path":"/pricing"}'{ data, meta, rows, statistics, data_status }) wrapped in the standard v1 envelope. (Earlier versions of this endpoint returned a short-lived our analytics warehouse JWT instead; that pattern was retired in GL#318 because the signing secret was never registered with our analytics warehouse, so every minted token was rejected with 401.)workspace_id and Admaxxer always supplies it from the API key — never from the request. website_id is IDOR-checked against the API-key workspace before any upstream call.data_status: "stale" instead of failing the request.The API version lives in the path: /api/v1/. Breaking changes bump the major version. Additive, backwards-compatible changes (new fields, new endpoints) ship on v1. Deprecations are announced with at least 90 days of notice in the changelog and via the Deprecation response header.
A hand-written OpenAPI 3.1 spec is maintained at server/openapi/pixel.yaml in the Admaxxer repository. We publish a copy at /api/v1/openapi.yaml so you can generate clients with your preferred tool (openapi-typescript, openapi-generator, Speakeasy, etc.).
Email support@admaxxer.com with the request_id from the response meta block. Every response carries one.
A small REST surface mounted at https://admaxxer.com/api/v1/ that exposes the same analytics data powering the in-app dashboards. It lets you mint our analytics warehouse-backed metric responses, list your pixel websites and goals, identify visitors, and ingest events server-to-server. Every endpoint is scoped to a single workspace by API key.
It can read all analytics pipes via /pixel/metrics/{pipe}, list websites/goals/alerts/reports/share-links, look up a visitor profile, ingest server-to-server events, and identify visitors. It deliberately cannot create or mutate goals, alerts, reports, or share links (UI-only to keep the blast radius small), return raw visitor PII (emails + phone are SHA-256 hashed at ingest), or run cross-workspace queries (a key is bound to exactly one workspace).
Create an API key in Settings › API Keys with the scopes you need (pixel:read for read endpoints, pixel:write for event ingest and identify). Pass it as Authorization: Bearer YOUR_KEY on every request. See Authentication for full details.
No (GL#318). The metrics endpoints server-side-proxy our analytics warehouse with the workspace admin token and return the literal pipe row payload (data, meta, rows, statistics, data_status) wrapped in the standard v1 envelope. Earlier versions returned a short-lived JWT; that pattern was retired because the signing secret was never registered with our analytics warehouse, so every minted token was rejected with 401.
The version lives in the path (/api/v1/). Breaking changes bump the major version. Additive backwards-compatible changes ship on v1. Deprecations are announced with at least 90 days of notice in the changelog and via the Deprecation response header.
Yes. A hand-written OpenAPI 3.1 spec is maintained at server/openapi/pixel.yaml in the Admaxxer repository and published at /api/v1/openapi.yaml. Generate clients with openapi-typescript, openapi-generator, Speakeasy, or any other tool that consumes 3.1.
Every response carries a meta.request_id field. Include it in any support email and the team can pull your exact request out of the server logs. The Errors page lists every error.code string with the cause and fix.