Members

Members belong to an organization in the AISIX Cloud control plane. They represent the people or service owners responsible for control-plane administration, API keys, usage, and limits.

The AISIX Cloud control plane supports two member onboarding paths:

• Invite a member when they need to sign in to the dashboard.
• Create a member directly when you need an API key owner that does not sign in to the dashboard. This path is available on an On-Premises control plane only.

Both paths create organization members. The difference is whether the member receives an invitation and can use the dashboard. An administrator can later enable sign-in for a member created directly.

On the SaaS service, people join an organization by invitation, through single sign-on, or through SCIM directory sync. Members cannot be created directly there.

An On-Premises control plane has no open sign-up: an invitation is the only way for a new person to create an account, unless the organization's single sign-on adds new members on sign-in.

With single sign-on configured, members can also sign in through your identity provider instead of with a password, and an invited person can accept the invitation by signing in through SSO.

Invite a Member

Use an invitation when the person needs dashboard access to manage resources, view usage, or administer the organization.

1. Open Members and select Invite member.
2. Enter the member's email address and choose a role.
3. Select Send invitation.

What happens next depends on whether the deployment has email configured:

• With email configured, the control plane emails the invitation link to the invitee. The invitation card confirms that the relay accepted the email. If the email was not delivered, the card shows why, such as a connection, TLS, or authentication failure, or the relay's rejection message. The invitation is still valid either way.
• Without email, nothing is sent. The card asks you to send the link to the invitee yourself.

In both cases, the card shows the invitation link once, so you can copy it and pass it on over a channel you trust. Anyone holding the link can open the invitation, so treat it like a credential. The control plane stores only a hash of it and cannot show it again after you leave the page; resend the invitation to get a new link.

Opening the link shows the invitee who invited them, which organization they are joining, and with which role. An invitee who does not have an account yet creates one from that page — the email address is filled in and cannot be changed — and comes back to the invitation. The account can be created only through the invitation link: the sign-up request carries the invitation's token, and the control plane refuses it when the invitation is no longer pending, has expired, or was issued to another address. The sign-up page opened without an invitation says that registration is disabled. Joining always takes an explicit Accept invitation: opening the link never changes membership on its own, which also means an existing user who is signed in to another organization is not moved by following it.

The invitation is bound to the address you entered. Only an account using that address can accept it; anyone else sees which address the invitation was issued to and is offered a way to sign in as that person. Until the invitee accepts, the invitation stays pending on the Pending invitations tab.

You cannot invite an address that already belongs to a member of the organization. Accepting an invitation never changes an existing member's role, so such an invitation would have nothing to do — change the role from the members list instead. An invitation also cannot bring back a member that SCIM directory sync deactivated: redeeming it returns 403 with the error code MEMBER_DEACTIVATED.

Invitation Lifetime

An invitation expires 7 days after it is sent. Until then it stays on the Pending invitations tab, where you can revoke it to invalidate the link immediately.

That tab lists live invitations only. Select Show stale invitations to also see accepted, revoked, and expired ones. An expired invitation can be revoked from there when you want to retire the record.

An expired invitation does not keep the email address reserved: inviting the same person again issues a fresh link and retires the lapsed invitation, which stays visible under Show stale invitations. Only an invitation that is still pending and valid blocks a second invitation to the same address.

Resend an Invitation

Select Resend on a pending invitation, or on an expired one listed under Show stale invitations, to issue it again. Resending creates a new link and the link issued before stops working. The invitation then expires 7 days after the resend. With email configured, the new link is emailed to the invitee again; the card shows the new link either way.

You can resend only an invitation you could have created with the same role. An invitation whose address has meanwhile joined the organization cannot be resent; cp-api returns 409 with the error code ALREADY_MEMBER.

Invitation Email Limit

With email configured, each account can send a limited number of invitation emails per rolling hour, 50 by default. The limit counts every organization the account belongs to, and creating and resending an invitation both count. Over the limit, the invitation is refused with 429 and nothing is created or reissued. On-Premises operators set the limit with api.smtp.invitationLimitPerHour; see Invitation Email Limit.

Sign Up on the SaaS Service

On the SaaS service, anyone can create an account from the sign-up page, and must confirm the email address before the account can be used:

1. Sign up with a name, an email address, and a password. The page then asks you to check your email, and no session is opened yet.
2. Open the verification link in the email. It opens the sign-in page with the email address filled in.
3. Sign in with the password you chose at sign-up. This verifies the email address and signs you in.

The verification link is valid for 24 hours and works once. It is completed by signing in with the account's current password, so a link that reaches the wrong person is of no use without that password. Opening the link alone changes nothing.

Until the address is verified, signing in with the password is refused with 403 and the error code EMAIL_NOT_VERIFIED, and the sign-in page offers to resend the verification email. A link that is invalid, expired, already used, or replaced by a newer one is refused with EMAIL_VERIFICATION_LINK_INVALID. A wrong password is refused with INVALID_EMAIL_OR_PASSWORD either way, so a sign-in attempt does not reveal whether an address is verified.

To get a new link, select Resend verification email on the check-your-email page or the sign-in page. Each new link replaces the earlier ones. A request made within a minute of the previous link is ignored and the earlier link stays valid. The page shows the same message whether the address has an account waiting for verification, so it cannot be used to find out who is registered.

Signing up again with an address whose account is still unverified replaces that sign-up: the new name and password take effect, the account's sessions end, and a new verification link is sent. An address whose account is verified, or that belongs to an account without a password, such as one created by SSO or SCIM, cannot be signed up again.

Resetting a forgotten password also verifies the email address, because the reset link was opened from that mailbox.

An On-Premises control plane does not verify email addresses. Accounts there come from invitations.

Reset a Forgotten Password

A member who has a password and forgot it can reset it from the sign-in page, when the deployment has email configured:

1. On the sign-in page, select Forgot?.
2. Enter the account's email address and select Send reset link.
3. Open the link in the email and choose a new password. The same password rules as sign-up apply.

The page shows the same message whether the address belongs to an account, so it cannot be used to find out who is registered. The reset link:

• is valid for one hour;
• works only once;
• replaces any earlier reset link for the account, except that a request made within a minute of the previous one is ignored and the earlier link stays valid.

Resetting the password signs the account out of every session, on every device. Sign in again with the new password. On the SaaS service, a reset also marks the email address verified.

Without email, the forgot-password page tells the user to contact an administrator and does not offer a form.

Accounts without a password do not receive a reset email. This includes directly created members, members provisioned through SCIM, accounts restored from a redacted backup, and users who only signed in with Google or GitHub before those sign-in options were removed. An administrator can enable sign-in for them instead.

Enable Sign-In or Reset a Password

On an On-Premises control plane, an administrator can give a member a one-time link on which the member sets their own password. The administrator never sees or chooses the password.

The Members list shows how each member signs in, read together with the organization's single sign-on connection:

• Can sign in, followed by the member's methods: Password, SSO, or both. SSO means the member is linked to an identity on the organization's enabled SSO connection, which happens at their first single sign-on.
• Signs in with SSO, for a member with no password and no SSO link yet while the organization's SSO connection is enabled. The identity provider admits them by their email address at their first single sign-on.
• Password · SSO required, for a member other than an owner who has only a password while the connection enforces single sign-on. The password alone does not let them in; they have to sign in through SSO. Only organization owners and admins, who can read the SSO settings, see this badge; other viewers see Can sign in (Password).
• Cannot sign in, for a member with neither a password nor an SSO link while no SSO connection is enabled.

A deactivated member shows only Deactivated, with no sign-in badge and no sign-in actions. For any other member, the row action depends on whether the member has a password:

• Reset password, for a member who has one. The current password keeps working until the member sets the new one.
• Set password, for a member without a password who can sign in through SSO. A password gives them a second way to sign in, but while single sign-on is enforced, a password alone does not let them in.
• Enable sign-in, for a member who has no way to sign in, such as one created directly, provisioned through SCIM, or restored from a redacted backup.

Selecting any of these actions shows a card with the link, which you can copy. With email configured, the control plane also emails the link to the member, in the organization's language or, when it has none, the deployment default, and the card says where it was sent or why the email was not delivered. Without email, nothing is sent: pass the link to the member yourself over a channel you trust. The card shows the link only once.

The link:

• is valid for 72 hours;
• works only once;
• stops working when you issue a newer link for the same member, when the member requests a reset from Forgot?, when you change the member's role or remove the member, or when SCIM directory sync deactivates or deletes the member;
• can be used only while its holder is still an active member of the organization that issued it. Otherwise it is refused as an invalid link.

A link cannot be issued for a deactivated member: the request returns 400 with the error code INVALID_REQUEST, and no email is sent.

When the member sets the password, every session of the account ends, and the member signs in with the new password. A link that expires unused changes nothing. The member's teams, roles, and API keys are not affected either way.

Anyone with write access to members, admin and owner by default, can issue a link for a member with the member role. Because whoever holds the link takes over the account, a link for anyone else needs the role that could invite them: only an owner can issue one for an owner, and a link for an admin or a member with a custom role needs a built-in admin or owner.

To issue a link from automation, call POST /members/{user_id}/set_password_link with a write-scoped admin token, using the member's user_id from the members list and the AISIX_CP and AISIX_TOKEN values described in Use the API. The response carries the link, its expires_at, the action (enable_sign_in or reset_password), and email_delivery:

export USER_ID="MEMBER_USER_ID"

curl -X POST "${AISIX_CP}/members/${USER_ID}/set_password_link" \
  -H "Authorization: Bearer ${AISIX_TOKEN}"

Create a Member Directly

On an On-Premises control plane, create a member directly when a service, application, or developer needs to own API keys without receiving dashboard access.

Creating a member directly is not available on the SaaS service. Its Members page has no Create user button, and POST /members returns 404. Accounts on the SaaS service are shared by every organization, so a member created directly would hold an account for an address that its owner never confirmed, and would block that person's own sign-up. Invite the person, or provision them through SCIM directory sync, instead.

A directly created member:

• Becomes active immediately, with no invitation link or confirmation step.
• Can be added to teams and assigned API keys.
• Can be governed with rate limits and budgets.
• Has no password, so it cannot sign in to the dashboard until an administrator enables sign-in.

The member still has a name and email address. Use values that identify the responsible person, service, or application owner so usage and limits can be attributed correctly.

In the Dashboard

1. Open Members and select Create user.
2. Enter a Name and an Email that identify the responsible owner.
3. Select Create user.

The member appears in the list right away. You can then add the member to a team and issue API keys from the environment that serves its traffic.

Use the API

Use the API when you need to provision members from automation.

Authenticate with an organization admin token that has write scope. Admin tokens are scoped to one organization, so the request does not need a separate organization header.

# AISIX_CP includes /api and has no trailing slash.
# The local On-Premises quickstart uses http://localhost:8080/api.
export AISIX_CP="YOUR_AISIX_CLOUD_ADMIN_API_URL"
export AISIX_TOKEN="YOUR_ADMIN_TOKEN"

Create the member:

curl -X POST "${AISIX_CP}/members" \
  -H "Authorization: Bearer ${AISIX_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Responsible Person",
    "email": "svc-payments@example.com"
  }'

A successful call returns 201 Created with the new member:

{
  "member": {
    "id": "8f3b2a1c-9d4e-4f6a-b7c8-1e2d3f4a5b6c",
    "user_id": "2c7d6e5f-4a3b-4c2d-8e1f-9a0b1c2d3e4f",
    "email": "svc-payments@example.com",
    "display_name": "Responsible Person",
    "role": "member",
    "sign_in_methods": []
  }
}

The email address must be valid and unique across the deployment. For an application owner, you can use a synthetic address such as svc-payments@example.com. Reusing an existing email address returns 409 Conflict. Directly created members always use the member role.

When attributing a caller API key to this member, use the membership id as the key's user_id. The member response also contains an account user_id, which is a different identifier used by member routes and team membership. Do not substitute that account ID for the caller-key attribution value.

Members Waiting to Join

On the SaaS service, SCIM directory sync records a user it provisions at an address outside the organization's verified domains as a member waiting to join, and invites the address. The Members page lists these people in a Waiting to join section below the members, with their email address, role, directory ID, and whether they are active, and the invitation appears on the Pending invitations tab. The section is hidden when nobody is waiting.

A waiting member becomes a regular member when the person accepts the invitation, or connects the organization's single sign-on with the identity the directory names. Manage waiting members in the identity provider. See Members Waiting to Join.

Browse and Search Members

The Members list supports search and pagination, so large organizations stay manageable.

• Use the search box to filter by name or email. The search runs server-side, so it matches across every page, not only the rows currently in view.
• Use the controls below the list to change the page size or move between pages.

List Members with the API

Reuse the AISIX_CP and AISIX_TOKEN values exported above. A token with read scope is sufficient for this request.

curl "${AISIX_CP}/members?page=1&page_size=20&q=payments" \
  -H "Authorization: Bearer ${AISIX_TOKEN}"

The query parameters are optional:

• q: case-insensitive match against member name and email.
• page: 1-based page number. Requires page_size; setting page on its own returns 400.
• page_size: page size, up to 200. Omit both page and page_size to disable paging and return every member in a single response.

The response wraps the members in a pagination envelope:

{
  "data": [],
  "total": 128,
  "page": 1,
  "page_size": 20,
  "owner_count": 2
}

total is the number of members that match the filter across all pages, and owner_count is the number of owners in the organization. On an On-Premises control plane, each member also carries sign_in_methods, which lists how the member can sign in: password when the member has a console password, and sso when the member is linked to an identity on the organization's enabled single sign-on connection. It is empty when the member can do neither, until a set-password link gives them a password or they sign in through single sign-on.

Remove a Member

Select the remove action on a member row. Removing a member takes their organization membership, their environment-scoped role bindings, and their place on every team.

It also disables every API key that member owns, and the change reaches the gateway, so those credentials stop authenticating there and not only in the dashboard. This is the same deprovisioning your identity provider triggers over SCIM — removing someone through the dashboard and removing them through the directory now leave the organization in the same state.

The keys are disabled rather than deleted, so their usage history stays available for reporting. A key an operator had already disabled by hand keeps that provenance. If the person's credentials should keep serving traffic after they leave — an application key created under their account, say — rebind or recreate them before removing the member.

When the member's account has no password and belongs to no other organization, removing the member also deletes the account, so its email address is free again. This covers members created directly, provisioned through SCIM, or created by single sign-on on their first sign-in. An account with a password, or one that is still a member elsewhere, is kept. Deleting the organization treats every member's account the same way.

Next Steps

Continue with Teams to group members for attribution and shared controls, or use Roles and Custom Roles to control member permissions. Use SCIM Directory Sync when your identity provider should manage membership, and Single Sign-On (SAML) when members should sign in through it.