Manage your end-users

Find accounts, invite users, revoke access, and review security activity.

Copy page

Open Users in your product to manage its end-user directory. You can find accounts, invite users, ban access, revoke sessions or passkeys, and schedule recovery for a lost second factor. Operations apply to the selected product.

Full erasure runs from the product’s data-processing settings. See Delete or erase an account.

The Users area includes these screens:

Open a directory row for Users → Users → <user>, or an endpoint for Users → Webhooks → Deliveries.

The product API also supports workflows without a dedicated screen: metadata changes, session lookup by ID, product-wide audits, retention settings, and service-level readings. See the Users REST reference for exact paths and fields.

Agents can perform management operations through MCP with a product-scoped token and the required access level. End-user access tokens do not grant operator rights.

Find a user

1. Open Users → Users. The directory lists newest accounts first and paginates results. Search by name or a full or partial email address, including its normalized form.
2. To look up a stable ID from your logs or a token, use users_users_get with product-scoped read access. The search box does not match IDs.
3. Open the matching row to inspect the record.

The status filters are All, Active, Banned, and Waitlisted. This view filters by search and lifecycle status, not authentication method, verification, or date range. Soft-deleted records are hidden; use users_users_list with read access and includeDeleted to include them.

Waitlisted records are excluded from the default directory view. Select Waitlisted or open the waitlist funnel.

Read a record

A user’s record groups identifiers, sessions, factors, and audit history beneath status and operator actions. It also provides profile editing and the support actions described below.

Identity: retain the stable user ID in your application database. Tokens and events use this ID. The record also holds the display name and image when supplied.

Identifiers: each email address has its own verification state, and one is primary. A user can hold both verified and unverified addresses. The section lists them without add or remove controls. Use Set primary email for the operator change workflow.

Sign-in methods: passwords and linked Google or GitHub identities are separate from email identifiers. API operations manage these methods; the record has no provider-unlink or password-clear screen. A user must retain a usable sign-in method.

Sessions: each row identifies a device by user agent and source address, with refresh and expiry times. Ended sessions remain marked in the list. Use the same session records for your application’s device list and operator revocation.

MFA factors: confirmed authenticator enrollment and remaining backup codes appear here. Passkey rows include the chosen name, transports, and last use. An enrolled passkey is also available as a verified factor.

Profile and metadata: metadata has three access boundaries:

Use public metadata for small claims your backend needs without a lookup, such as a plan or role. Its token projection is size-limited; oversized writes are rejected before they can break sign-in.

Security history: inspect the record’s Audit trail for authentication and operator activity, as described below.

Create and invite a user

1. On Users → Users, choose Invite user and enter an email and optional name.
2. The recipient follows the email link to choose a first credential. This is also the entry path for invite-only sign-up.

To create a record without email, choose Create user instead. Its verification checkbox records your assertion; select it only with evidence that the address is verified. Neither dialog accepts metadata. Use users_users_create or users_users_invite with product-scoped write access to supply publicMetadata and privateMetadata.

Invitations are single-use, expire, and can be revoked before acceptance while retaining the record. Re-inviting the address returns the same user. Acceptance follows the configured sign-up flow and its password and authentication requirements.

Edit a record

Profile and metadata writes update the directory immediately. Public-metadata changes appear in subsequently issued access tokens, within the configured token lifetime. Edit profile fields in the Profile section; use the API or an agent for metadata.

To request a primary-address change:

1. Choose Set primary email on the record.
2. Enter the new address and a written reason describing identity proofing and any support reference. The audit stores that reason verbatim against your identity.
3. Submit the request. It waits for the operator-override delay in emailChange; both addresses are notified so the change can be stopped.

Only a verified address can become primary. Users uses it for contact and for the token’s email claim.

Address removal must leave a usable sign-in route. The last verified address available for email-code sign-in cannot be removed when it is the account’s only way in.

Reset a lost second factor

If the user has lost both their authenticator and backup codes, choose Reset MFA in MFA factors. When the reset takes effect, it clears enrolled factors and revokes all sessions so the user can enroll again.

Revoke a passkey

Choose Revoke on a passkey row in MFA factors. Supply the required written reason; the audit preserves it with your identity. The API and agent path support the same operation.

Revocation takes effect immediately and removes only that credential. There is no delayed cancellation window.

A passkey cannot be revoked if it is the account’s last sign-in method. The check considers all identifiers and credentials, and operator permissions do not bypass it. The user must establish another method first.

Revoke a session

In Sessions, choose Revoke for one device or Revoke all in the section header and confirm. Ended sessions have no revoke action. Refresh stops immediately for a revoked session.

To inspect a session ID from logs without first finding its user, read the session through the product API. The app only lists sessions on the user record.

An access token already issued can still pass local verification until it expires, ten minutes by default. Use checked verification where immediate revocation is needed. See Sessions and tokens and lifetime configuration.

Ban and unban

Choose Ban from the directory row or user-record header, then confirm. Banned records offer Unban in those locations; unbanning takes effect without a separate confirmation.

Banning blocks new sign-ins and revokes existing sessions. Profile, identifiers, and metadata remain. Unbanning restores sign-in with the existing credentials. Use a ban when access may be restored; use deletion when retiring an account.

Impersonate a user for support

To reproduce a support issue, open Impersonation on the user record and choose Sign in as …. Enter the required written reason. The same operation is available through the API and to an agent.

The action is disabled when the product has no allowlisted return address or the operator lacks permission to create the session. The card explains the reason.

The card displays an access token and session ID with a copy action. It does not redirect or sign into your application automatically. Your application must accept and verify the returned token through its own support-session integration. Impersonation has these limits:

• Dedicated permission is required; directory access alone is insufficient.
• The session lasts at most thirty minutes and has no refresh token.
• It cannot change passwords, factors, addresses, or sessions.
• The session is marked as impersonated, so your backend can withhold sensitive actions.
• The audit includes the operator and verbatim reason. Unless notifications are disabled, the user receives an email containing that reason.

Delete or erase an account

Choose Delete in the user-record header to retire an account, then read and confirm the consequences. Request full erasure from the product’s workspace settings under Data processing → Forget a person.

Before deletion or erasure, Export on Users → Users can download the full filtered directory as CSV. It walks every result page, reports progress, and records the export. Migration covers the formats and the exclusion of password hashes.

See Data and privacy for retention and erasure behavior across the platform.

Import users in bulk

Use Users → Import to paste rows or select a file and map email, name, and optional supported password-hash columns. Review parse errors before submitting, then inspect the final per-row report for created, skipped, or failed. Existing verified-address collisions are skipped during import, not detected by the parser preview. Follow Migration for the exact programmatic record shape.

The import preserves these rules:

• Created rows use the identifier verification state supplied; explicitly mark unconfirmed addresses unverified.
• Supported foreign hashes are checked at the first successful sign-in and replaced with argon2id.
• Omit unsupported hashes and plan a password reset or invitation. Invalid import rows fail individually; a bad digest is not automatically made usable.
• Records without credentials can be invited afterward. Import itself sends no email.

The run produces one audited batch operation and a per-row report. Verify counts and a representative sign-in in a non-production product before cutover.

Read the audit trail

Use the user view for support and the product-wide view for operator investigations.

The Audit trail on a user record shows actions, timestamps, and actors. Refresh reloads it in place. It includes authentication, device, credential, address, factor, session, ban, impersonation, and erasure activity. Entries are append-only; the app cannot edit or remove them.

For product-wide operator activity, use the API or an agent. These entries include both app users and agents. The app exposes one user’s trail at a time and has no product-wide actor view.

users_audit_list requires product-scoped read access and filters by action, target, and time range. Read the actor from each entry; there is no actor filter. Entries also carry source address, browser, and time. Notifications for password changes, new devices, email-change requests, and pending MFA resets give the affected user a separate record of sensitive activity.

Read the numbers

Users → Overview groups counts into Users (total, active, waitlisted, banned, deleted, erased), Sessions, Second factors, Sign-ins, and Abuse signals. Abuse signals cover lockouts, MFA lockouts, failed sign-ins, breached passwords, and refresh-token reuse.

The selector offers 24 hours, 7 days, 30 days, and 90 days. Current user, live-session, and factor populations ignore that window. Sign-in counters, established sessions, and abuse signals use it. Each metric labels its scope. A window without attempts shows No attempts, not a zero-percent success rate.

Two additional read-only views are available through the product API or an agent:

• Retention settings describe how long Users keeps each category of data.
• Service-level readings report measured service behavior for the product.

These readings have no dedicated app screen and do not themselves create a service-level guarantee.

Next steps

• Authentication configuration for methods, policies, and lifetimes.
• Sessions and tokens for verification after revocation.
• Migration for import and export contracts.
• Waitlists for managing access before launch.