Skip to main content
An API key authenticates programmatic access to TinyAnalytics—server-side event ingestion, analytics reads, site management, SQL, and MCP. Create either a full-access key or a restricted key with per-resource permissions in Settings → Account, then send it on every request as a Bearer token:

​
Create and manage keys

Keys are managed from your account settings:
  • A key is shown once at creation — copy it then, because TinyAnalytics stores only a hash and can’t show it again.
  • Revoke a key any time to cut off its access immediately.
  • A key inherits its owner’s access: a request authenticates as the user who created the key, and is authorized by that user’s organization membership and team access. A key never grants more than its owner has.
  • Leave Restrict permissions off for full access, or turn it on and select at least one resource for a least-privilege key. A restricted key is refused on any API route outside its grants.

​
Which permissions can I grant?

Selecting Write also selects Read for that resource when both actions exist. It does not grant read or write access to any other resource. Existing keys created without a permission list remain full-access keys.
For workflows, use Workflows: Read. Although the shared permission model includes a write grant, creating, editing, publishing, testing, pausing, resuming, archiving, and cancelling require an owner or admin signed in with a dashboard cookie session in workflow version 1.
A restricted key with Sites: Read can list the organizations and sites its owner may access, but organization-list responses omit member rosters. Cookie sessions and existing full-access keys retain the complete member directory.
Treat an API key like a password. A leaked full-access key can use every API capability its owner can access; a leaked restricted key can use every grant you selected. Keep keys server-side, never ship one in browser code, and revoke an exposed key. Browser tracking needs no key—the data-site-id in the snippet is enough.

​
Where the key is required

​
Sending the key

Always send the key in the Authorization header — never in the URL. A key in a query string leaks into server logs, browser history, and referrer headers.

​
Frequently asked questions

No. A key is shown once at creation, because TinyAnalytics stores only a hash of it. If you didn’t copy it, create a new key in your account settings and revoke the old one.
No — always send it in the Authorization header as Bearer YOUR_API_KEY. A key in a query string leaks into server logs, browser history, and referrer headers.
A full-access key can use every API capability its owner can access. A restricted key can use only its selected resources and actions, still bounded by the owner’s organization and team permissions. Revoke either key immediately in account settings. Keep keys server-side and never ship one in browser code.
Yes, but only for the same resource. Selecting Goals: Write, for example, also selects Goals: Read; it does not grant Funnels, Sites, or any other resource. Write-only Event ingestion has no matching read permission.
API-key creation is limited to 10 attempts per signed-in user each hour. Invalid creation requests count toward the same security limit. A 429 response includes Retry-After; wait for that window before trying again.

Tracking API

Use a key for server-side ingestion.

Rate limits & CORS

The per-key ingestion limit.

Account settings

Where you create and revoke keys.

API playground

Try the API with your key.

MCP server

Use the same key to connect an AI agent.

Related topics

TinyAnalytics Account SettingsTinyAnalytics Agent Skills for AI Coding AgentsWebsite and API Uptime Monitoring