Bulk export users

The opposite of import. Pull a snapshot of users out of the tenant.

How to trigger

Users → Actions → Export users.

You're asked:

Format — CSV or NDJSON.
Filter — every user, or only matching the current filter on the list view (state: active, created_after: 2025-01-01, etc.).
Fields — pick which fields to include. Default includes the everyday ones; toggle on for picture, locale, custom attributes, group memberships, MFA factor counts (the factor secrets themselves are NEVER exported — they don't leave the platform).
Anonymise — toggle. When on, emails and names are replaced with [redacted]; user_ids are preserved. Useful for compliance-evidence exports where the data leaves your perimeter.

Click Start export. The platform queues an export job; the UI shows progress. Small exports (< 10K users) complete in seconds; larger ones are minutes.

What you get back

The export job produces a single file. You download it via the Export jobs panel under Users → Actions.

CSV:

user_id,email,name,given_name,family_name,state,email_verified,created_at,last_signed_in_at,groups
usr_01HZ...,anita@cymmetri.com,Anita Singh,Anita,Singh,active,true,2026-01-15T10:00:00Z,2026-05-17T08:00:00Z,"Engineering,Beta Testers"

NDJSON:

{"user_id":"usr_01HZ...","email":"anita@cymmetri.com","name":"Anita Singh","state":"active","email_verified":true,"created_at":"2026-01-15T10:00:00Z","groups":["Engineering","Beta Testers"]}

What's NEVER exported

The platform doesn't include these in any export:

Password hashes — even encrypted ones. Passwords never leave the platform. If you're migrating users elsewhere, the destination platform must trigger its own password-set flow per user.
MFA factor secrets — TOTP shared secrets, WebAuthn private keys (which only ever existed on the user's device anyway), SMS phone numbers in plaintext (only last-4 if the schema includes phone fields).
Refresh tokens — they're per-session and not part of the user record.
Federated identity tokens — the Google / GitHub / SAML linked-identity records carry the external sub but not any tokens from the federated provider.

The exclusion is principled: the export shouldn't be useful to an attacker who exfiltrates it.

Use cases

Backup before a risky change

Export before bulk-disabling a group, before tightening the authentication policy, before any large config change. The export is your "what did the user records look like before" rollback reference.

Migration to another platform

Filter to the relevant users, export NDJSON, transform with a script, import to the destination. The destination platform's import contract will differ; the transformation is yours to write.

Compliance evidence

A regulator or auditor asks "show me your user records as of date X". Use the export-with-filter to capture just the snapshot they need; share the file via a secure channel.

Reconciliation with a downstream system

Export, diff against your CRM's user list, find drift. Build a one-off remediation.

Audit + retention

Every export emits user.bulk_export in audit, capturing:

The actor (you).
The filter applied.
The fields included.
The row count.
An export-job id you can reference.

The export FILE itself is retained on the platform for 7 days, then auto-purged. If you need a longer-lived copy, download promptly and store in your own systems (with appropriate access controls — the file contains PII).

Streaming vs single-file

For tenants with very large user populations (> 100K), the streaming export pattern is the way: hit the management API's stream endpoint with NDJSON content-type; the platform writes rows as it reads them. Doesn't materialise the whole result set anywhere.

The UI export above buffers the result into a single downloadable file; works fine to ~100K but slower past that.