Full access and read-only keys

You choose a key’s kind when you create it, and it keeps that kind for life. To change what a key may do, revoke it and create a new one. The form describes each kind in a line. Full access: Reads and writes — subscribers, segments, webhooks. Read-only: Reads everything, changes nothing.

Your code wants to	Full access	Read-only
Read subscribers, segments, custom fields, forms, and automations	✓	✓
Add or update a subscriber	✓	—
Record that someone unsubscribed	✓	—
Add someone to a segment or take them out	✓	—
Create a segment or a custom field	✓	—
Set up a webhook	✓	—

A read-only key that asks to change something is refused. The request fails on the developer’s side, with a reason they can read. Nothing in your workspace changes. If you only want a dashboard, a report, or a backup, read-only is the safer choice.

The permission statement

For full access, you tick one sentence before you can select Create key: Everyone I add with this key asked to hear from me. No bought, rented, or scraped lists.

The statement is the same promise the CSV import asks for, and for the same reason: a full access key is a door into your list. What the wording means is in The permission statement.

Jounce records who ticked the statement and when, with the key. A read-only key can’t add anyone, so it skips the statement.

A key belongs to the workspace

A key reaches the whole workspace it was made in. That’s every subscriber, segment, form, and automation, whoever created the key. It’s not tied to your sign-in: if you leave the workspace, the key keeps working. Revoking it switches it off; see Revoke an API key.

The card’s own line holds: A key is a password for this account — keep it server-side. Anyone who has the key has its access. So keep it in the code on your server, never in a web page or an email.

Who can create one

Admins and Managers create and revoke keys. An Editor can see which keys exist and read the docs; see Workspace roles.