Skip to main content
Settings is a set of tabs, and a tab appears only when there is something behind it. Not greyed out, not an empty card, not a red error: absent. An agent sees no tab strip at all, just their own preferences. Each tab has an address. /settings?tab=people is a link a colleague can paste, and /users lands there too. Email and SMS are settings of an organisation, so those two tabs carry the organisation picker. The rest are the platform’s or your own, where a tenant picker would mean nothing.

​
You

Your password. At least 12 characters, and length is the only rule: a long phrase beats a short pattern. Your current password is asked for, so a session somebody left open cannot quietly change the lock. Changing it signs out every other session you have. Two-step sign-in. A six-digit code emailed at each password sign-in. A browser you choose to remember skips it for 30 days. Your current password is asked for to turn it on and to turn it off, for the same reason. The operator can require it for everybody, in which case it cannot be switched off here.
Two-step does not apply to an agent signing in with an extension and a PIN, and it cannot be switched on before the platform’s email works, because the code arrives by email.
This session is a read-out of what your login actually resolved to: your role, the control plane you are talking to, the organisations in scope and the permissions granted. It is reference. You read it when something is wrong.

​
People & access

Staff logins: operator admins, organisation admins and team supervisors. Invite, edit, disable, delete.
Agents are deliberately not here. An agent’s login exists to carry a PIN, and the PIN is issued on Teams & agents beside the extension it answers on. Two screens offering the same login is what leaves somebody with an account and no phone attached to it.

​
Inviting somebody

A new login is invited by email by default: they get a link, choose their own password, and nobody else ever knows it. The link is good for 7 days, and there is one live invitation per login at a time. The platform’s email has to work first. The check happens before the login is created, because an invitation that cannot be sent would leave an account nobody can ever open. Where email is not set up, give the login a password instead. You can send the link again later from the same editor.

​
Roles

Three roles are assignable: operator admin, organisation admin, team supervisor. The role is a starting point; what the account may actually do is the permission set the server resolves from it. See roles. Four rules the server holds, whatever the form offers:
  1. You may not create or assign a role above your own. Said that way rather than “only an operator may make an operator”, so it keeps holding if a role is ever added between two existing ones.
  2. Your own role and your own sign-in are another administrator’s to change. Demoting yourself is a lockout with nobody left to undo it, and disabling yourself is the same thing sooner. Your email and password stay yours.
  3. A supervisor’s login needs a team. It is what bounds whose calls they see, and the team must belong to their own organisation.
  4. The organisation is fixed once the login exists. Moving a login between tenants would move a person’s history with them, so there is no way to do it.

​
Disabling, and deleting

Disable is the kill switch, and it takes effect on their next request rather than when their token expires. Everything they made stays. It is reversible. Delete asks you to type the email. What they created stays and the record of what happened survives; who did it becomes “a deleted login”. You cannot delete your own.

​
API keys

Also on the Developer page, with the request log and the console.
  • An integration key belongs to the organisation and survives people leaving. A personal key acts as you, within your role.
  • A key can never outrank its owner. Its permissions are intersected with the role of whoever made it, so revoking the person revokes their keys. Even a full-access key cannot manage keys or create people.
  • Every key must say where it is used from. A key with no address list is a password that works from anywhere on the internet, so the API refuses to make one. Keys made before that rule keep working for a grace period and are shown with the addresses they were actually used from, so they can be allowed in one step.
  • The secret is shown once. Only a hash is kept.
  • Editing changes the address list and the rate limit. Permissions cannot change; a different access means a new key.
Each key shows when it was last used and when it was last refused, with the address each time.

​
Integrations

HTTP connections are your own systems, called by an IVR flow’s Fetch data step: a base URL plus the headers it needs. Header values and the signing secret are write-only — the list shows which headers are set and whether requests are signed, and editing leaves the stored values alone unless you type new ones. Webhooks post call events to your own URL as they happen, signed with a secret generated here and shown once. Deliveries are retried for about 15 hours. The delivery log, the callback inbox and a test inbox are on the Developer page.

​
Where the rest lives

Several things people look for on Settings are deliberately elsewhere: There is no Security tab and no Branding tab.