Users

users_users_import

Bulk-import end users into this product, up to 500 rows per call — batch client-side beyond that.

Tool

users_users_import

Bulk-import end users into this product, up to 500 rows per call — batch client-side beyond that.

Bulk-import end users into this product, up to 500 rows per call — batch client-side beyond that. Hashes only: pass `password.phcHash` for an argon2id PHC string, or `password.foreignHash` + `foreignHashAlgo` (bcrypt/argon2/pbkdf2/scrypt) for a hash from the system you are migrating off. A foreign hash is stored INERT — nothing verifies it until sign-in lands in Phase 2, where it is checked once and rehashed — so set `requiresReset: true` on rows whose source hash you do not trust. IDEMPOTENT by canonical identifier: a row whose email already exists VERIFIED in this product is skipped, not duplicated, so re-running the same file is safe. Imported identifiers default to verified (unlike users_users_create) — pass `verified: false` per identifier for addresses the source system never confirmed. Returns a PER-ROW report ({row, status, userId, reason}) plus counts: one malformed row never fails the batch. Emits ONE batch event (`users/user.imported`, with counts) rather than a per-user created event, and writes ONE audit row.

Behavior

HTTP: POST /users/users/import

Arguments

Name	Type	Required	Description
users	array	•	The users to import, at most 500 per call — batch client-side beyond that. Each row: identifiers (email), optional profile, optional password HASH, optional flags.

Response

Field	Type	Always
failed	integer	•
created	integer	•
results	array	•
skipped	integer	•
requested	integer	•

Try it

Bulk-import end users into this product, up to 500 rows per call — batch client-side beyond that.

When to use

Example

Ask your agent something like this:

Bulk-import end users into this product, up to 500 rows per call — batch client-side beyond that.

The agent will invoke users_users_import with these arguments:

{
  "users": "<users>"
}