API key types and scopes
Use test keys in dev/staging and live keys only in production environments.
Grant the minimum scopes required by each workflow (plans:read, entitlements:read, etc.) — see the Entitlement Evaluation Patterns guide for how those scopes map to the boolean/limit/metered check shapes you'll actually call.
Publishable-key exception: the embed funnel beacon
One endpoint departs from the least-privilege rule above. The embed SDK's activation-funnel beacon, POST /api/v1/events/funnel, accepts a browser-embedded publishable key for its write and is exempt from the per-key scope check. Its only route-specific write is a single anonymous, workspace-scoped funnel-telemetry record (widget_view or checkout_started); like every authenticated request it may also stamp the workspace's first-API-call activation timestamp. It touches no tenant business data or configuration, so no scope is required. This is the only write a publishable key may perform — keep secret keys server-side and expose only the publishable key in browser widgets. See the Events guide for the beacon's request body and embed-SDK usage.
Bearer header
curl -H "Authorization: Bearer $MONETIZEKIT_API_KEY" "$MONETIZEKIT_BASE_URL/plans?page=1&pageSize=1"X-API-Key header
curl -H "X-API-Key: $MONETIZEKIT_API_KEY" "$MONETIZEKIT_BASE_URL/entitlements/cust_001/api_access"CI token policy
Prefer dedicated service accounts for CI with read-only scopes by default. Rotate CI tokens regularly and revoke old tokens after rollout completion.
Never echo secrets in logs; reference request IDs for traceability instead — see the Audit and Trace guide for how request IDs propagate across the API, webhooks, and the audit log.