# Supabase Auth admin API: the server-side user management rules
Creating, updating, and deleting users programmatically goes through the admin API with the service role key. Agents get two things wrong: calling it from the client (leaking the key) and treating it as casual CRUD (no audit trail for destructive actions).
## Checkable procedure
1. Build a dedicated admin client with the service role key, used only in server code: Edge Functions, API routes, admin scripts. Never import it into frontend code.
2. For user creation, prefer invites (`inviteUserByEmail`) over `createUser` when the user should set their own password. `createUser` with a password you chose is a credential you now own.
3. Deleting a user is irreversible and cascades to their data per your foreign keys. Confirm the cascade behavior before deleting: check what `on delete` your FKs use, or you orphan rows across the schema.
4. Updating user metadata via the admin API bypasses the user's own update path. Log who did what and when; admin writes without an audit trail are indistinguishable from a breach.
5. Never expose admin operations through an unauthenticated endpoint. Every admin route must verify the caller is an admin (check a role claim with `getClaims()`), not just that they are logged in.
## Quick test
Perform each admin operation from a test script and confirm it works. Then try the same operation with the anon key and confirm it fails. If the anon key succeeds at admin work, your key wiring is wrong.