> For the complete documentation index, see [llms.txt](https://docs.sendman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sendman.com/admin-portal/settings/permissions.md).

# Permissions

Permissions and Sendman REST API access tokens can be managed under https\://YOURNAME.sendman.com/settings/permissions

## Overview

The **Permissions** page controls who can sign in to the Sendman Admin Portal, what they can do there, and which API access tokens exist for the [Sendman REST API](/other/rest-api.md).

{% hint style="success" %}
Sendman does not store or manage its own administrator identities. Administrators sign in with their existing accounts at one of the supported identity providers and do not need additional accounts.
{% endhint %}

<figure><img src="https://1641814212-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4EVg4twS3gtObqtkynsm%2Fuploads%2Fgit-blob-9e05c65a2eab2730439a7450dc1da6411f1be021%2Fpermissions.png?alt=media" alt="Permissions page"><figcaption></figcaption></figure>

{% hint style="info" %}
Changes to sign-in providers, roles and the token cutoff only become effective after clicking **Save permissions**. **Discard changes** reverts all unsaved changes.
{% endhint %}

## Sign-in providers

Under **Sign-in providers**, you enable the identity providers that administrators and viewers may use to sign in, for example Microsoft Entra ID or Google. Each provider shows its state:

* **Active · in use:** you are currently signed in with this provider.
* **Enabled:** users can sign in with this provider.
* **Disabled:** this provider cannot be used to sign in.

At least one provider must stay enabled. To prevent a lockout, you cannot disable the provider you are currently signed in with.

### Custom OIDC provider

Under **Custom OIDC provider**, you can add your own OpenID Connect provider to use another identity provider, e.g. Okta.

1. Click **Edit** next to **Custom OIDC provider**.
2. Register an application at your identity provider and use the redirect URL shown in the dialog (`https://YOURNAME.sendman.com/loginserver/authResponse`).
3. Enter the **Display Name**, **Authentication URL**, **Token URL**, **Client ID**, **Client Secret** and **Client Scope** of this application.
4. Save the dialog.

{% hint style="warning" %}
After saving or deleting the custom OIDC provider, the Admin Portal restarts. The new sign-in option is available after the restart. The client secret is never displayed again, so you have to re-enter it whenever you edit the provider.
{% endhint %}

## Roles

Under **Who has access**, you grant people one of two roles. Each entry consists of the identity provider (if more than one is enabled) and the account's e-mail address or user principal name (UPN). A wildcard grants access to a whole domain, e.g. `*@contoso.com`.

### Administrators

Accounts listed here have **full control**:

* View and change the [IP Allow List](/admin-portal/sendman/ip-allow-list.md), [Authorization Policies](/admin-portal/sendman/authorization-policies.md) and [SMTP Credentials](/admin-portal/sendman/smtp-credentials.md)
* View and change all settings, including [Network Connections](/admin-portal/settings/network-connections.md), [SMTP Client](/admin-portal/settings/smtp-client.md) and [SMTP Backend](/admin-portal/settings/smtp-backend.md)
* View the [Insights](/admin-portal/insights.md) dashboards
* Manage permissions and [API access tokens](#api-access-tokens)

To prevent a lockout, you cannot remove yourself from the administrators.

### Viewers

Accounts listed here have **read-only** access. They can view all settings of the Sendman menu group and the settings pages, but cannot change them. API access tokens are not visible to viewers.

## Session security

During sign-in to the Admin Portal, each user obtains an access token that is cached in the browser. After an offboarding or a suspected leak, you can force everyone to sign in again:

1. Under **Invalidate tokens issued before**, click **Set cutoff to now**.
2. Click **Save permissions**.

All tokens issued before the cutoff become invalid. This includes your own session, so you have to sign in again. [API access tokens](#api-access-tokens) are not affected; delete them individually if needed.

## API access tokens

Under **API access tokens**, you manage long-lived tokens for scripts and integrations that call the [Sendman REST API](/other/rest-api.md).

### Add

1. Click **Add Access Token**.
2. Enter a **Name** that describes the purpose of the token.
3. Select the **Role**: **Administrator** for read and write access, **Viewer** for read-only access.
4. Select when the token **Expires in**: 90 days, 180 days, 1 year or 2 years.
5. Confirm the dialog.

<figure><img src="https://1641814212-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4EVg4twS3gtObqtkynsm%2Fuploads%2Fgit-blob-f5ab601f6a80609d5176662bedb5eea7f0e1e2cc%2Fpermissions-add-token.png?alt=media" alt="Add access token dialog" width="563"><figcaption></figcaption></figure>

{% hint style="warning" %}
The token is displayed only once. Copy it and store it somewhere safe before you click **Done**. If you lose it, delete the token and create a new one.
{% endhint %}

### Delete

Click the delete icon of a token. Requests using this token are rejected immediately.

The table shows each token's **Name**, **Role**, when it **Expires**, and its **State** (enabled or expired).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.sendman.com/admin-portal/settings/permissions.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
