Migrate from Auth0

✅ Verified

Axowl side against POST /api/public/v1/end-users/import — 2026-08-15. Auth0 export policy per Auth0’s user migration docs and their password-hash export article.

Start the support ticket first

Auth0’s bulk export does not include password hashes. You must open an Auth0 support ticket for a PGP-encrypted hash export, which can take a week or more and is tied to plan level. File it on day one, migrate everything else while you wait — or skip hashes entirely, since Axowl signs users in without them.

1. Export from Auth0

Create a bulk user export job via the Management API (POST /api/v2/jobs/users-exports) — output is newline-delimited JSON with user_id, email, name, and metadata. Hashes (bcrypt) arrive separately via the support ticket, keyed by user_id.

2. Import

const hashByUserId = loadHashExport();          // from the support-ticket file, if you got one
const rows = auth0Users.map(u => ({
  email: u.email,
  displayName: u.name || null,
  sourceUserId: u.user_id,                      // "auth0|…", "google-oauth2|…", …
  passwordHashAlgorithm: hashByUserId[u.user_id] ? "bcrypt" : null,
  passwordHash: hashByUserId[u.user_id] || null,
}));
// POST in batches of 500 with source: "auth0" — loop as in the Clerk guide.

Gotchas

• user_id encodes the connection (auth0|, google-oauth2|, github|…). Keep the full string in sourceUserId; social users need no hash at all — they carry over by email.
• Unverified emails: imported users start as Pending either way, and their first magic-link sign-in verifies the address — Auth0’s email_verified flag doesn’t need translating.
• Rules/Actions don’t migrate. Inventory what your Auth0 Rules did (claims, allowlists) and map them to App Group settings before cutover.
• Hashes are stored dormant — see how the import works.