Security & API keys
Security is where you protect your organization and the data it holds. It gives you a guided checklist of recommended actions, controls over how people sign in, and a place to manage the keys that let other systems connect to you. A few minutes here meaningfully reduces your risk. Admin only
Harden your organization
Work through the Security Guide
Follow the checklist of recommended actions — it walks you through retention, residency, sign-in and survey collection, and tracks what's done.
Set your session policy
Decide whether people can have multiple concurrent sessions or must use a single session at a time.
Manage your API keys
Create the API keys you need for programmatic access, and revoke any you no longer use.
Security Guide
The Security Guide is a checklist of recommended actions that strengthen your organization. It prompts you to configure data retention and anonymisation, choose your data residency, enable multi-factor authentication, and secure how your surveys are collected. As you complete each item, the guide tracks your progress so you can see what's left.
Several items link straight to the relevant settings — for example retention and residency live in Data management & residency.
User Security
User security controls how people sign in. You can allow multiple concurrent sessions, or force a single session so each user is only signed in one place at a time. Multi-factor authentication (MFA), which adds a second step at sign-in, is on the way. Coming soon
Organization API keys
An organization API key lets external systems call the e-satisfaction API on behalf of your whole organization — across all workspaces — within the permissions you grant it. It's how you build automations and integrations on top of your data. Admin only Managing API keys is an admin action.
A key is not tied to a person — treat it like a password
An organization API key is not tied to a single user. Anyone holding it can call the API across your entire organization and all workspaces, within the permissions you grant. Because it isn't bound to one account, it keeps working regardless of who joins or leaves the organization — so you can build long-lived integrations on top of it without them breaking when a person's account changes. That power is exactly why you should treat a key like a password: share it only with systems that need it, store it securely, and revoke any key that may have been exposed.
Creating a key
When you create a key you set three things:
| Setting | What it means |
|---|---|
| Name | A label so you can recognise where the key is used. Choose something descriptive, like the system or integration it powers. |
| Expiration | How long the key stays valid — 1 day, 1 week, 1 month, a custom date, or never expires. Choosing "never" creates a permanent credential, so use it deliberately. |
| Permissions (scopes) | The specific operations the key is allowed to perform — for example read alerts, create / read / update queue items, read pipelines, and so on. Tick only what the integration needs. |
The key itself is shown once, at creation — copy it then and store it safely, because it can't be shown again. Afterwards you can rename a key, but its scopes and expiry are fixed. To change what a key can do or how long it lasts, create a new key and retire the old one.
Managing keys
You can revoke a key at any time. Revocation takes effect immediately — any integration using that key stops working at once — so revoke as soon as a key is no longer needed or may have been exposed. You can also clean up expired keys to keep the list tidy.
API token activity — monitoring the requests made with your organization's tokens — is on the way. Coming soon
When you build an integration against these keys, the developer reference in the Survey Manager developer guide shows how to authenticate and call the API.
Related
Data retention
Data residency
Developer guide
Identity & Account
For your personal sign-in and profile, see Identity & Account.