Skip to content

Users

users_users_set_primary_identifier

OPERATOR OVERRIDE of a user's primary email address, for the case the normal flow cannot serve: the old address is unreachable (dead mailbox, imported user), so the user cannot approve the change themselves.

Tool

users_users_set_primary_identifier

OPERATOR OVERRIDE of a user's primary email address, for the case the normal flow cannot serve: the old address is unreachable (dead mailbox, imported user), so the user cannot approve the change themselves.

OPERATOR OVERRIDE of a user's primary email address, for the case the normal flow cannot serve: the old address is unreachable (dead mailbox, imported user), so the user cannot approve the change themselves. This does NOT swap the address now. It SCHEDULES the swap behind this product's mandatory delay (config `emailChange.overrideDelayHours`, default 72) and immediately emails the OLD address an abort link; if that mailbox is alive and its owner clicks, nothing happens. When the delay elapses the address is swapped, verified, and EVERY SESSION of that user is revoked. Every step is audited (`email_change.override_scheduled` / `_cancelled` / `_applied`) with the `reason` you pass, so do the identity proofing first and write down what it was. Use users_users_update for profile fields; this tool is only for the identity a user signs in with.

Behavior

HTTP
POST /users/users/:userId/primary-identifier

Arguments

NameTypeRequiredDescription
emailstringThe address to make primary. Must not already belong, verified, to another user of this product.
reasonstringWhat identity proofing was done and under which ticket. Recorded verbatim in the audit row — this is the whole point of the tool being audited.
userIdstringThe user whose primary email address is being replaced.

Response

FieldTypeAlwaysDescription
requestIdstring
scheduledForstring

Try it

OPERATOR OVERRIDE of a user's primary email address, for the case the normal flow cannot serve: the old address is unreachable (dead mailbox, imported user), so the user cannot approve the change themselves.

When to use

OPERATOR OVERRIDE of a user's primary email address, for the case the normal flow cannot serve: the old address is unreachable (dead mailbox, imported user), so the user cannot approve the change themselves. This does NOT swap the address now. It SCHEDULES the swap behind this product's mandatory delay (config `emailChange.overrideDelayHours`, default 72) and immediately emails the OLD address an abort link; if that mailbox is alive and its owner clicks, nothing happens. When the delay elapses the address is swapped, verified, and EVERY SESSION of that user is revoked. Every step is audited (`email_change.override_scheduled` / `_cancelled` / `_applied`) with the `reason` you pass, so do the identity proofing first and write down what it was. Use users_users_update for profile fields; this tool is only for the identity a user signs in with.

Example

Ask your agent something like this:

OPERATOR OVERRIDE of a user's primary email address, for the case the normal flow cannot serve: the old address is unreachable (dead mailbox, imported user), so the user cannot approve the change themselves.

The agent will invoke users_users_set_primary_identifier with these arguments:

{
  "email": "<email>",
  "reason": "<reason>",
  "userId": "<userId>"
}

Esc

Start typing to search the docs.

navigateselect