> ## Documentation Index
> Fetch the complete documentation index at: https://docs.firetone.com.au/llms.txt
> Use this file to discover all available pages before exploring further.

# Settings

> Your own sign-in, who else may sign in, and the connections to your own systems. A tab you cannot see is a tab with nothing behind it.

**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.

| Tab                                     | Who sees it                                    |
| --------------------------------------- | ---------------------------------------------- |
| **You**                                 | everybody                                      |
| **People & access**                     | whoever may read users or API keys             |
| **AI**                                  | where the AI module is on                      |
| **Integrations**                        | organisation admins, and supervisors read-only |
| **SMS**                                 | whoever may read the SMS account               |
| **Email**, **Mobile push**, **Modules** | the operator only                              |

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.

<Note>
  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.
</Note>

**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.

<Note>
  **Agents are deliberately not here.** An agent's login exists to carry a
  PIN, and the PIN is issued on [Teams &
  agents](/tenant/phone-system/teams-and-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.
</Note>

### 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](/guides/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:

| Looking for                                                | It is on                              |
| ---------------------------------------------------------- | ------------------------------------- |
| retention windows                                          | the organisation, under Organisations |
| an agent's PIN                                             | Teams & agents                        |
| branding, the base domain, sign-up and the two-step policy | the operator's **Email** tab          |
| blocked addresses                                          | the operator's Firewall screen        |
| the API console and request log                            | Developer                             |

There is no Security tab and no Branding tab.