API Keys & Credentials
Project keys, project secrets and scoped API tokens
IForevents has two kinds of credentials. Pick the one that matches where the code runs.
| Credential | Lives in | Grants | Rotate from |
|---|---|---|---|
| Project key | apps, browsers, SDKs | ingest for one project | Settings → Project |
| Project secret | your servers | with the key: read-only analytics for that project | Settings → Project |
API token (ifmcp_…) | scripts, MCP clients | the scopes you pick, across the organization | Settings → API tokens |
Project key and secret
Every project gets a key and a secret when it is created. The key is public by design: it ships inside your app and only allows POST /v1/events/*. The secret is shown once and stored hashed; paired with the key in X-Project-Key and X-Project-Secret it reads that project's analytics from your servers. Shipping it in an app or a browser is deprecated and unsupported: see Authentication for the migration.
Rotate either one from Settings → Project (or POST /v1/projects/{uuid}/key/rotate and /secret/rotate). Old values stop working immediately, so ship the new key before rotating in production.
API tokens
Tokens are organization-level bearer tokens for scripts and MCP clients. Create them under Settings → API tokens:
- Name: how it appears in the list.
- Scopes: what it may read. The catalog is served by the accounts service:
analytics:read,projects:read,users:read,export:readand the opt-inusers:piifor unmasked contact details. - Project: all projects or one.
- Expiry: 30 days, 90 days, a year, a custom date, or never.
The token starts with ifmcp_ and is shown once. The list shows a masked preview, the scopes, creation, last use and expiry. Rotate issues a new token for the same entry (the old one stops at once); Revoke disables it for good.
The Free plan allows 5 active tokens per organization; paid plans have no cap. Only owners and admins with a verified email can create, rotate or revoke tokens.
Handling secrets safely
- Never commit secrets or tokens; load them from environment variables or a secrets manager.
- Use one token per integration so a leak can be revoked without collateral damage.
- Prefer expiring tokens for anything that is not a long-running service.