Users
Eight core methods, four tag methods, eleven credential methods.
Status and scope
Proposed target SDK catalog based on the verified current public SDK surface. It is not an implemented user directory or permission to expose organization administration in browser code. Generated stamp* builders and older version aliases are transport details and are not counted as separate business methods.
A User is a member of one organization. It may hold authenticators, API-key records, OAuth provider links, MFA policies and user tags. It is not a wallet, blockchain signer or application. Reads and mutations are always organization scoped; a foreign identifier returns a non-disclosing failure.
Core user methods#
| Method | Meaningful input | Result or effect |
|---|---|---|
getUser |
organizationId, userId |
one safe user projection |
getUsers |
organizationId |
all visible users in the organization |
createUsers |
requestId, one or more user definitions, each with at least one accepted credential path |
one durable operation whose result contains created user IDs |
updateUser |
requestId, userId, explicit profile/tag replacement fields |
one guarded user update; omission never clears a field |
updateUserName |
requestId, userId, userName |
name-only update |
updateUserEmail |
requestId, userId, userEmail, verification token when required |
verified email set or explicit removal when the accepted contract permits it |
updateUserPhoneNumber |
requestId, userId, E.164 phone number, verification token when required |
verified phone set or explicit removal when permitted |
deleteUsers |
requestId, non-empty userIds |
guarded deletion result containing the affected IDs |
The broad updateUser method and the three focused update methods are all retained because the verified source exports them separately. Bindings must not reinterpret a focused contact update as an unverified broad update. Batch creation and deletion are single submitted business actions; partial success must be explicit if an accepted backend contract ever allows it.
User-tag methods#
| Method | Meaningful input | Result or effect |
|---|---|---|
listUserTags |
organizationId |
organization-scoped tag records |
createUserTag |
requestId, name, initial user IDs |
one tag and its initial associations |
updateUserTag |
requestId, tag ID, optional new name, add/remove user IDs |
atomic association/name update |
deleteUserTags |
requestId, tag IDs |
guarded deletion result |
Tags are selectors and administration metadata. A tag does not grant wallet or policy authority by itself.
Attached credential methods#
These eleven verified server/core methods complete the user resource inventory. The browser-oriented flow and React convenience handlers remain in Frontend authentication; that page is not a competing user contract.
| Resource | Read methods | Mutation methods | Boundary |
|---|---|---|---|
| API keys | getApiKey, getApiKeys |
createApiKeys, deleteApiKeys |
public-key records may be managed; secret key material is generated and retained only by its authorized owner |
| Authenticators | getAuthenticator, getAuthenticators |
createAuthenticators, deleteAuthenticators |
attestation/challenge validation and minimum-factor policy apply |
| OAuth providers | getOauthProviders |
createOauthProviders, deleteOauthProviders |
verified issuer/subject linkage; profile or email equality never links accounts |
MFA-policy methods, session helpers, OTP/social/passkey flows and account-authentication recovery are already cataloged in document 18. They remain access mechanisms around users, not additional user CRUD aliases.
Runtime and authorization#
| TypeScript browser | TypeScript server | React adapter | Python server | Go server |
|---|---|---|---|---|
| Current-user/scoped reads and changes only when a server-issued grant permits them | Organization administration target | Calls the TypeScript core in a client component; no user-admin hook is implied | Organization administration target | Organization administration target |
Arbitrary user listing, batch creation/deletion, user-tag administration, API-key administration and cross-user credential changes are privileged server or explicitly authorized admin operations. A browser bundle must contain no server credential. A session identifying one user does not permit editing another user, changing approval membership or deleting a last required factor.
const user = await sdk.getUser({ organizationId, userId });
const created = await admin.createUsers({ organizationId, requestId, users });
user = await sdk.get_user(GetUserInput(organization_id=organization_id, user_id=user_id))
created = await admin.create_users(CreateUsersInput(
organization_id=organization_id,
request_id=request_id,
users=users,
))
user, err := sdk.GetUser(ctx, &GetUserInput{OrganizationID: organizationID, UserID: userID})
if err != nil { return err }
created, err := admin.CreateUsers(ctx, &CreateUsersInput{
OrganizationID: organizationID,
RequestID: requestID,
Users: users,
})
The examples are schematic proposed wrappers. They preserve exact organization scope and native naming without claiming released imports.
Durable action and failure contract#
Every mutation uses the shared stable requestId contract and returns an operation envelope. Same identity and same material converges; changed material conflicts. Timeout after dispatch is an unknown outcome recovered with getOperation, never a reason to repeat creation, deletion or credential enrollment under a new identity.
Rejected, stale, foreign, denied, expired-confirmation or minimum-factor-violating input changes nothing. Deleting a user must fail when it would violate the organization's approved root-approval or recovery rules unless an explicit, independently authorized replacement is part of the same accepted atomic action.
Acceptance#
- Positive: all eight core methods, four tag methods and eleven attached-credential methods are discoverable with exact organization scope and typed results.
- Positive: current-user browser flows and organization-admin server flows converge on the same server-enforced user state.
- Negative: login, a profile field or a tag never creates wallet authority; foreign user IDs disclose nothing; omitted fields never clear contact or access data; failed batch work is never reported as complete.
See Organizations, Application configuration, Approvals, and Frontend authentication.