Files
zitadel/apps/docs
6bd46c5fb6 feat(login): idp userAction oneof (#12433)
Closes #11369

# Which Problems Are Solved

During SSO login with an external IdP, Actions v2 lets you manipulate
the `RetrieveIdentityProviderIntent` response to shape the user that
ZITADEL creates or updates. There was an inconsistency between the two
flows:

- **First login (user does not exist):** the response carried an
`addHumanUser` object (mirroring the deprecated `AddHumanUser` API),
which **does** allow setting user `metadata`.
- **Subsequent logins (user exists):** the response carried an
`updateHumanUser` object (mirroring the deprecated `UpdateHumanUser`
API), which does **not** support metadata.

As a result, actions could set metadata when creating a user but not
when updating one. Customers doing SSO attribute mapping had to make a
separate `SetUserMetadata` call on every subsequent login — extra
latency and a non-atomic update. The proto/backend already gained a
non-deprecated `user_action` oneof (`create_user` → `CreateUserRequest`,
`update_user` → `UpdateUserRequest`, both supporting metadata), but the
login app was still reading the deprecated flat fields, so the new
capability was unreachable from the frontend.

# How the Problems Are Solved

Migrate the login app's IDP intent handler to consume the new
`user_action` oneof, with a fallback to the deprecated fields so older
API responses keep working during the transition.

- **`zitadel.ts`** — added `createUser` / `updateUser` client wrappers
calling the non-deprecated `UserService.CreateUser` /
`UserService.UpdateUser` endpoints.
- **`idp-intent.ts`** — added three helpers, each preferring
`user_action` and falling back to `add_human_user` /
`update_human_user`:
- `resolveCreateUser` — flat read view for org resolution,
required-field checks, and registration-form pre-fill.
- `buildCreateUserRequest` — passes the action's `CreateUserRequest`
through and injects the resolved `organizationId`; maps the deprecated
flat payload into the nested shape on fallback.
- `buildUpdateUserRequest` — builds an `UpdateUserRequest` **including
metadata** (the fix); deliberately syncs only
profile/email/phone/metadata (not username) to preserve existing
auto-update behavior and avoid invalidating sessions.
- Rewired all handlers (`handleUserExists`, `handleAutoLinking`,
`handleAutoCreation`, `handleManualCreation`,
`resolveOrganizationForUser`) to use these, and switched auto-create to
read `CreateUserResponse.id`.
- **Tests** — updated mocks/assertions to the new request shapes and
added two cases exercising the `user_action` oneof with metadata (create
+ update). 817/817 login unit tests pass; no new type errors.

# Additional Changes

Updated the Actions v2 guide
`guides/integrate/actions/testing-response-manipulation.mdx` (the
unreleased/`latest` docs) to reflect the new response shape:

- Go handler example now manipulates `resp.GetCreateUser()` /
`resp.GetUpdateUser()` and appends `user.Metadata`, demonstrating
metadata on both flows.
- Both JSON payloads switched from `addHumanUser` to the nested
`createUser` shape (`human.profile`, `human.email`, `human.idpLinks`,
top-level `metadata`).
- Added a Callout explaining first-login → `createUser` vs.
existing-user → `updateUser`, that both support metadata, and that
`addHumanUser`/`updateHumanUser` are deprecated.
- Updated the claim-mapping debugging section to the new
`createUser.human.profile.givenName` path.

Versioned snapshots (`v4.12`/`v4.13`/`v4.14`) were intentionally left
unchanged, as they document releases where the old API was correct.

---------

Co-authored-by: gayathri <[email protected]>
2026-07-16 12:01:07 +02:00
..
2026-01-30 18:11:12 +00:00

@zitadel/docs

Documentation for Zitadel, built with Fumadocs and Next.js.

Getting Started

Ensure you have followed the root quick start to set up dependencies.

Local Development

Ensure all dependencies are installed:

pnpm install

Start the development server:

pnpm nx run @zitadel/docs:dev

The site will be available at http://localhost:3000.

Scripts

Key scripts for documentation workflows:

Script Description
dev Starts the development server.
build Builds the production application.
fetch:remote-content Fetches remote tags and referenced content.
generate Runs all generation steps (fetch:remote-content, generate:proto-docs, generate:api-reference, generate:index-pages).
check:links Validates content integrity (broken links, missing frontmatter, schema errors).
check-types Validates typescript types.
test Runs all validation steps (check-types, check:links).
lint checks for code style and syntax errors (ESLint).
clean Cleans the build output and generated files.

Validation

  • Code Quality: Run pnpm nx run @zitadel/docs:lint to check for syntax and style issues in JS/TS/MDX files.
  • Content Integrity: Run pnpm nx run @zitadel/docs:check-links to validate content structure, including:
    • Broken internal links
    • Missing required front-matter (e.g., title)
    • Image references

Troubleshooting

Issue: Nx configuration not found or "nx" command not found

If you see errors like:

 NX   Cannot find configuration for task @zitadel/zitadel:@zitadel/docs:generate

Pass --verbose to see the stacktrace.

or

pnpm nx run @zitadel/docs:dev
 ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL  Command "nx" not found

Did you mean "pnpm nx"?

Root cause: Your dependency cache or node_modules is out of sync.

Solution: Run these commands from the repository root in order:

  1. Clear node_modules: rm -rf node_modules — removes the installed dependency folder
  2. Clear pnpm cache: pnpm cache delete — clears pnpm's internal package cache
  3. Reinstall dependencies: pnpm install — reinstalls all dependencies fresh
  4. Test the setup: pnpm nx run @zitadel/docs:generate — verifies everything works

This resolves 99% of setup-related issues.

Contributing

Build Process

The docs build process automatically handles the following steps via generate:

  1. Downloads required protoc plugins.
  2. Generates gRPC documentation from proto files.
  3. Generates API documentation from OpenAPI specs.
  4. Generates index files for directory structures.

Style Guide

  • Variables: Use environment variables in code snippets where possible.
  • Embedded Content: Use _filename.mdx for content embedded in other pages (not indexed individually).
  • Code Embedding: Use the file property in code blocks to embed code from the repo.
  • Voice: Use active voice and sentence case for titles.

Refer to the Google Developer Style Guide for general guidelines.

Adding Content

All documentation content is located in the content directory. Note that the system strictly accepts only .mdx files.

To add a new page:

  1. Create a .mdx file in the appropriate subdirectory of content.
  2. Register the new page in the sidebar settings at lib/sidebar-data.ts to make it accessible in the navigation.

Pull Requests

Use docs(<scope>): <short summary> for PR titles. Pass quality checks before submitting:

pnpm nx run @zitadel/docs:build