These docs are for AuthRocket 1. Looking for AuthRocket 2 docs?


Users are in many ways the core of AuthRocket. A user is either a person (a human user) or a system account (an api user).

The list of users can be filtered by type (human or API), state (active or inactive), or creation date (signup date). If there is an active filter, the Filter button will be green.

Additionally, the list may be sorted by clicking on any column header. To reverse the sort, click on the column header a second time.

The list of users may be exported as a CSV. The export will use the same filter and sort rules as the currently viewed list. This makes it super easy to do things like export a list of active users created in the last 30 days.

Users may also be bulk deleted by first selecting users using the icon at the left of each row and then clicking Delete at the top.

Adding and updating

Adding new users has separate buttons for human and API type users. Note that human users created this way are given a password to login. API users will auto-generate an API key instead.

First and Last names

A human user’s first and last names.


For system/API type users, an editable name for the user record. For humans, a read-only combination of their first and last names.


The user’s email address. Optional for API users.

Email verification state

Whether the email address is considered verified or not.

  • Unverified - Email is unverified and no further action is being attempted
  • Request verification - Initiates the email verification process
  • Verified - The email is considered verified, either from completing the verification process or by being marked verified directly

When changing a previously verified email address, if you want to re-verify using the new email, this must be set back to Request verification.


The user’s username required for logging in. For human users, when the realm is configured to use emails as usernames, then this must be a valid email address too. For API users, will be auto-generated if blank.


Indicates whether this user is active. If not, all logins and other activity will fail.


Reference is an optional ID that you can use to map the user to a corresponding resource in your app. If you store some kind of user record in your app, you might set that ID here (or alternatively, store AuthRocket’s user ID in your app record). This field is searchable via the API. Also see Custom attributes.

Password & Password again

Used to set or change the user’s password.

Custom attributes

Custom attributes may be added to any User. These are useful for storing a variety of extra data about users, from addresses and phone numbers, to timezones or anything else needed by your app.

These are a series of keys and values. Any scalar type, or array of scalar types] is valid for the value. Both keys and values are case-sensitive.

Types are mostly auto-detected. For example, 1 will be detected as an integer and
elephant will be seen as a string. To force a non-string to be stored as a string, use quotes: "1".

Custom attributes are not searchable. For a searchable field, use reference.

Managing users

In addition to editing various user data fields, several other direct operations are available.

For human users, passwords may be directly reset. Additionally, password reset tokens may be generated so the user can reset their own password.

If the user has any connected social network profiles, those are shown and can be deleted. Deleting an external profile connection does not prevent it from being re-added later based on email address matching.

For API users, the API key may be regenerated. If the realm is set to encrypt API keys, then the key may also be shown.

If two-factor authentication is enabled, the User’s 2FA device may be managed. If the user replaces or loses their device, delete the old device and add a new one.


Memberships come in two flavors: a membership that connects the User to an Org, and a membership only associated with the User.

User-only memberships are useful for adding permission attributes directly to the user.

User-to-Org memberships may or may not include permissions, depending on your app’s needs.

Permissions can be used for more than just permissions, but also as tags that describe the relationship between the User and the Org. See Memberships & Permissions for more.


If the realm is using managed sessions, the User’s active sessions will also be shown. Any session can be forcefully logged out (assuming your app periodically whether the session is still active). Expired sessions will automatically be removed.


Events connected to this user will also be shown. See Events for additional details.

Questions? Find a Typo? Get in touch.