Profile, Password, And API Tokens

Your profile controls how you appear in the Dashboard, how you authenticate, and how external systems connect to Incido on your behalf. Keeping these settings current is both a usability concern (correct timezone, recognizable name) and a security concern (strong password, controlled API tokens).

Editing your profile

Open your profile from the user menu in the Dashboard. You can update your given name, family name, email address, and timezone.

Your timezone affects how dates and times are displayed throughout the Dashboard. If you travel or work across time zones, updating this setting ensures that incident timestamps, maintenance windows, and scheduled events appear in your local time. When you change your timezone, the Dashboard stops showing timezone mismatch notifications for the rest of your session.

Your email address must be unique across all active accounts. Changing it invalidates any pending password reset tokens, so if you have an outstanding reset link, it will stop working after the email change.

Your name is visible to other operators in your organization — for example, in internal comments and audit trails. Use a name your team will recognize.

Changing your password

You can change your password from the same profile page. Enter your new password and confirm it. After the change, any pending password reset tokens are invalidated for security.

Choose a strong password and rotate it according to your organization's security policy. If you use shared credentials (which is discouraged), coordinate with your team before rotating.

API tokens

Incido uses personal access tokens for programmatic access to the HTTP API. They are the bridge between your operator identity in the Dashboard and the automation that runs outside the browser — CI/CD pipelines, monitoring integrations, internal tools, or one-off scripts. A token always acts as you: it does not create a separate service account, so anything the integration does appears in audits and permission checks under your user.

How Dashboard sign-in differs from API authentication

When you use the Dashboard in a browser, you sign in with your email and password (or your organization’s chosen sign-in flow). The application keeps you in a session inside that browser; you do not paste a secret on every click.

The API works differently. Each HTTP request from an integration must carry your token using Bearer authentication: the client sends an Authorization header whose value is the word Bearer followed by a space and the token secret your integration stored after creation. If that header is missing, invalid, or revoked, the API responds as unauthenticated. This model is standard for machine-to-machine access; your job as an operator is to issue tokens sparingly, store them only in secure configuration, and revoke them when an integration is retired or suspected of compromise.

Most API operations that touch tenant data are tied to a specific organization through the URL (for example, paths that include an organization identifier). The API evaluates whether you may act in that organization the same way the Dashboard would: you must be a member, and your role there still applies. A small number of endpoints are documented without requiring a bearer token; those exceptions are explicit in the API reference introduction. For everything else, assume the token is required.

Scopes, roles, and why both matter

When you create a token, you choose how tightly to constrain what it may do. All scopes gives the token the broadest API allowance that your account can still exercise — Incido will still enforce your Dashboard permissions per organization, so you cannot elevate yourself through a token. Custom scopes narrows the token further: even if you are an administrator in the organization, a minimally scoped token can only perform actions that fall within the scopes you selected. That is deliberate: a read-only monitoring integration should not carry credentials that could change production data.

In practice, Incido checks the token’s scopes first, then applies the same permission rules you would see when clicking through the Dashboard for the organization targeted by the request. The token never grants more than you could do manually under those two layers together.

Creating, expiring, and limiting tokens

Open API Tokens from your user menu (top right in the Dashboard). That page is separate from the profile fields for your name and email; it exists specifically to list, create, and revoke tokens. When you create a token, give it a name your future self will understand — for example “PagerDuty outbound” rather than “token 3” — because that name is what you will see when auditing or revoking access later.

During creation you decide whether the token should receive all scopes or custom scopes, whether it should never expire, or expire after a number of days (within the limits shown in the form). The plaintext secret is displayed once at creation; copy it into your secret store or integration configuration immediately. Incido cannot show it again afterward.

You can have up to ten active tokens at a time (tokens that are not revoked and are not past their expiry). If you hit that limit, revoke an old or unused token before creating another.

Revoking a token is immediate: the next request that presents that secret fails authentication. Use revocation when an integration is decommissioned, when a colleague who knew the secret leaves, or whenever you suspect leakage.

Token hygiene remains the same discipline as passwords. Do not commit tokens to source control, paste them into chat, or share one token across unrelated systems. Prefer environment variables or your platform’s secret manager, rotate on a schedule that matches your risk tolerance, and prefer narrower scopes when the integration allows it.

Access control and multi-tenancy

Your user account can belong to multiple organizations. When you log in, the Dashboard shows the organizations you are a member of, and your permissions are evaluated in the context of whichever organization you are currently working in.

This means that having admin permissions in one organization does not grant you any access in another. Each organization membership is independent, and your role and permissions are scoped to that specific organization.

API tokens follow the same model. A token authenticates as your user, but each API request must identify an organization you belong to when the operation is tenant-specific — typically through the organization segment in the request path. You cannot retarget the same token at a different organization’s identifiers and expect access; membership is always evaluated for you and that organization together.

What changes on the public frontend

Profile, password, and token changes do not affect your public status pages. These settings control operator access and integration capabilities, not customer-facing content.

Operational effects

Profile and token hygiene affect operational reliability indirectly. Incorrect timezone settings can lead to communication mistakes in incident and maintenance timing, and unmanaged tokens can create unauthorized automation behavior. Keep these settings aligned with your operational workflows in Incidents and Maintenances.

Troubleshooting

You cannot log in after changing your email. Verify you are using the new email address. If you had a pending password reset, it was invalidated by the email change — request a new one using the updated email.

An API token is not working. Confirm the token has not been revoked and has not passed its expiry if you set one. Check that the integration sends the header in the form Authorization: Bearer <your secret> with no stray quotes or line breaks. Verify the request URL refers to an organization your user belongs to when the operation is organization-scoped. If you used custom scopes, confirm the operation you need is allowed by those scopes; otherwise recreate the token with a broader scope set or with all scopes, still subject to your Dashboard role in that organization.

Dates and times look wrong in the Dashboard. Check your timezone setting on your profile page. If you recently traveled or your browser timezone does not match your profile, update the timezone and reload the Dashboard.