Reference

Permissions explained

Every permission Nerja asks for — in the browser, on Android, on iOS, in Firebase and for API keys — what it is for and what happens without it.

Nerja asks for as little as it can. This page lists every permission by place, what it is for, and what simply does not work if it is missing.

Website visitors' browsers#

Permission / storage	Why	If missing
First-party cookie + localStorage	Recognise a returning visitor and keep unsent events across pages	Each visit looks like a new person; abandoned carts cannot be linked
Form values (consent: identity / full)	Create a lead from an email/phone typed into a form	No lead until the visitor logs in or you call identify()
Notification permission (web push)	Allow your site to show a notification	No web push; email/SMS/WhatsApp still work
Service worker (web push)	Receive a push while the page is closed and report delivery/click	No web push

Privacy

Password, card, CVV, bank, SSN, PIN and one-time-code fields are never read — at any consent level.

Android#

Permission	Type	Why	If missing
`INTERNET`	Install-time (added by the SDK)	Send events and tokens to Nerja	Nothing works
`ACCESS_NETWORK_STATE`	Install-time (added by the SDK)	Retry sensibly when offline	Retries are less efficient
`POST_NOTIFICATIONS`	Runtime, Android 13+	Let the system show your pushes	Pushes are delivered to the device but not displayed — ask at a good moment with requestNotificationPermission()
`WAKE_LOCK` / `com.google.android.c2dm.permission.RECEIVE`	Merged by Firebase	Receive FCM messages	No push

iOS#

Capability / prompt	Why	If missing
Push Notifications capability	Obtain an APNs device token	No device token, so no push (and a free Apple account cannot enable it)
Background Modes → Remote notifications	Receive pushes and updates in the background	Reduced delivery behaviour
Notification permission prompt	Let iOS display the push	Token still registers; nothing is shown
Local Network (debug builds only)	Reach a development API on your LAN	Only affects testing against a local server

Firebase#

What	Why
Service-account key (JSON)	Lets Nerja ask FCM to send messages for your project. Nerja stores only the project id, service-account email and private key, encrypted.
Firebase Cloud Messaging API (V1) enabled	The send API Nerja uses; enabled by default on new projects.
APNs authentication key (iOS)	Lets Firebase hand notifications to Apple.
Web push key / VAPID (web)	Lets browsers subscribe to your project.

API keys and scopes#

Key type	Where to use	Notes
`PUBLIC_TAG`	Browsers and mobile apps	Safe to publish. Browsers must come from your allowed website; apps from an allowed app id. Can only write events/tokens.
`SECRET`	Your server	Never put it in a page or app. No origin check; higher rate ceiling.

Scope	Allows
`events:write`	Send events, identify users, register devices
`events:read`	Read stored events
`profiles:read / profiles:write`	Read or modify customer profiles
`segments:read / segments:write`	Read or manage audiences
`campaigns:read / campaigns:write`	Read or manage campaigns
`webhooks:write`	Manage outgoing webhooks
`integrations:write`	Manage provider integrations

Tip

A public key needs only events:write. Give server keys the smallest scope list that does the job.

Workspace roles#

Role	Can
Owner / Admin	Everything, including connecting providers (Firebase, email, SMS), API keys and launching campaigns
Member	Works in the dashboard and can see integrations; cannot connect providers or manage API keys
Viewer	Read-only dashboards

When you connect Shopify, WooCommerce or Salla, the permissions are shown on the store's own approval screen — approve only what is listed there. Salla connections additionally need permission to register webhooks so orders and customers arrive without a tracker snippet.

Prefer to talk it through? Book a 30-minute call with the Nerja team.

Something unclear or missing? Email support@nerja.ai and we will improve this page.