Skip to content

feat(generated): Add user management operations and models (+1 more)#123

Merged
workos-sdk-automation[bot] merged 4 commits into
mainfrom
oagen/batch-a7de29ef
Jul 2, 2026
Merged

feat(generated): Add user management operations and models (+1 more)#123
workos-sdk-automation[bot] merged 4 commits into
mainfrom
oagen/batch-a7de29ef

Conversation

@workos-sdk-automation

@workos-sdk-automation workos-sdk-automation Bot commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Summary

feat(user_management): Add user management operations and models

  • Added model SendRadarSmsChallenge.
  • Added model SendRadarSmsChallengeResponse.
  • Added model UrnWorkosOAuthGrantTypeRadarEmailChallengeCodeSessionAuthenticateRequest.
  • Added model UrnWorkosOAuthGrantTypeRadarSmsChallengeCodeSessionAuthenticateRequest.
  • Added model MagicAuthSendMagicAuthCodeAndReturnResponse.
  • Added model UserCreateResponse.
  • Added ip_address to CreateMagicCodeAndReturn.
  • Added user_agent to CreateMagicCodeAndReturn.
  • Added radar_auth_attempt_id to CreateMagicCodeAndReturn.
  • Added signals_id to CreateMagicCodeAndReturn.
  • Added ip_address to CreateUser.
  • Added user_agent to CreateUser.
  • Added signals_id to CreateUser.
  • Added signals_id to AuthorizationCodeSessionAuthenticateRequest.
  • Added signals_id to PasswordSessionAuthenticateRequest.
  • Added radar_auth_attempt_id to PasswordSessionAuthenticateRequest.
  • Added radar_auth_attempt_id to UrnWorkosOAuthGrantTypeMagicAuthCodeSessionAuthenticateRequest.
  • Added endpoint POST /user_management/radar_challenges.

fix(user_management): Update user management API surface

  • Changed request body for UserManagementAuthentication.authenticate.
  • Changed response of UserManagementUsers.create from User to UserCreateResponse.
  • Changed response of UserManagementMagicAuth.sendMagicAuthCodeAndReturn from MagicAuth to MagicAuthSendMagicAuthCodeAndReturnResponse.

Triggered by workos/openapi-spec@71b13e0

BEGIN_COMMIT_OVERRIDE
feat(user_management): Add user management operations and models (#123)
fix(user_management): Update user management API surface (#123)
END_COMMIT_OVERRIDE

@workos-sdk-automation
workos-sdk-automation Bot merged commit 0ed9dc6 into main Jul 2, 2026
8 checks passed
@workos-sdk-automation
workos-sdk-automation Bot deleted the oagen/batch-a7de29ef branch July 2, 2026 17:34
@greptile-apps

greptile-apps Bot commented Jul 2, 2026

Copy link
Copy Markdown

Greptile Summary

This auto-generated PR extends the WorkOS Rust SDK to support Radar-aware authentication flows, adding new request/response models and a new POST /user_management/radar_challenges endpoint for sending SMS challenges.

  • New Radar SMS challenge endpoint: Adds CreateRadarChallengeParams, SendRadarSmsChallenge, SendRadarSmsChallengeResponse, and create_radar_challenge method with full error-scenario test coverage.
  • Breaking return type changes: create_user now returns UserCreateResponse (only radar_auth_attempt_id) instead of User, and create_magic_auth now returns MagicAuthSendMagicAuthCodeAndReturnResponse (same) instead of MagicAuth — existing callers accessing any field on the returned object will fail to compile.
  • New Radar signal fields: Adds signals_id, ip_address, user_agent, and radar_auth_attempt_id as optional fields across multiple request models (CreateUser, CreateMagicCodeAndReturn, PasswordSessionAuthenticateRequest, AuthorizationCodeSessionAuthenticateRequest, MagicAuthCodeSessionAuthenticateRequest, RadarStandaloneAssessRequest).

Confidence Score: 3/5

Two public API methods change their return types to stripped-down wrappers, which will cause compilation failures in any downstream crate that uses the returned object's fields.

The new Radar SMS challenge endpoint and signal field additions are straightforward and well-tested. However, create_user and create_magic_auth now return types that only carry radar_auth_attempt_id — all User and MagicAuth data fields are gone from the response. Any consumer code that reads the returned user id, email, or magic auth fields will fail to compile. This is faithfully generated from the updated spec, but merging will require coordinated downstream updates and likely a major version release.

src/resources/user_management.rs deserves a close look at the create_user and create_magic_auth signatures and their new return types before merging.

Important Files Changed

Filename Overview
src/resources/user_management.rs Return types of create_user and create_magic_auth changed to thin wrappers that only carry radar_auth_attempt_id, dropping all previously-available User and MagicAuth fields — breaking changes for existing SDK consumers.
src/models/user_create_response.rs New model faithful to the updated spec; only contains radar_auth_attempt_id (optional), no user data fields.
src/models/magic_auth_send_magic_auth_code_and_return_response.rs New response model with only radar_auth_attempt_id; correctly uses SecretString for sensitive fields elsewhere in the PR.
src/models/send_radar_sms_challenge.rs New request model for the SMS challenge endpoint; pending_authentication_token typed as SecretString — correct.
src/models/radar_sms_challenge_code_session_authenticate_request.rs New authenticate request model for SMS challenge grant type; client_secret and pending_authentication_token use SecretString.
src/models/radar_email_challenge_code_session_authenticate_request.rs New authenticate request model for email challenge grant type; sensitive token fields correctly typed as SecretString.
tests/user_management_test.rs Comprehensive error-scenario tests added for the new create_radar_challenge endpoint; round-trip tests for create_user and create_magic_auth inline "{}" rather than using the new fixture files.
src/models/mod.rs Module declarations and re-exports added for all new models; consistent with existing patterns.
src/models/create_user.rs Added ip_address, user_agent, and signals_id optional fields; all use skip_serializing_if with Option correctly.
src/models/create_magic_code_and_return.rs Added ip_address, user_agent, radar_auth_attempt_id, and signals_id; correctly optional and consistent with the rest of the request models.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant Client
    participant UserManagementApi
    participant WorkOS API

    Note over Client,WorkOS API: Radar SMS Challenge Flow (new)
    Client->>UserManagementApi: create_radar_challenge(SendRadarSmsChallenge)
    UserManagementApi->>WorkOS API: POST /user_management/radar_challenges
    WorkOS API-->>UserManagementApi: SendRadarSmsChallengeResponse {verification_id, phone_number}
    UserManagementApi-->>Client: Ok(SendRadarSmsChallengeResponse)

    Client->>UserManagementApi: authenticate(RadarSmsChallengeCodeSessionAuthenticateRequest)
    Note right of Client: includes verification_id from above
    UserManagementApi->>WorkOS API: POST /user_management/authenticate
    WorkOS API-->>UserManagementApi: AuthenticationResponse
    UserManagementApi-->>Client: Ok(AuthenticationResponse)

    Note over Client,WorkOS API: create_user — return type change
    Client->>UserManagementApi: create_user(CreateUserParams)
    UserManagementApi->>WorkOS API: POST /user_management/users
    WorkOS API-->>UserManagementApi: UserCreateResponse {radar_auth_attempt_id?}
    UserManagementApi-->>Client: Ok(UserCreateResponse)
    Note right of Client: No User fields (id, email, etc.) returned anymore
Loading
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant Client
    participant UserManagementApi
    participant WorkOS API

    Note over Client,WorkOS API: Radar SMS Challenge Flow (new)
    Client->>UserManagementApi: create_radar_challenge(SendRadarSmsChallenge)
    UserManagementApi->>WorkOS API: POST /user_management/radar_challenges
    WorkOS API-->>UserManagementApi: SendRadarSmsChallengeResponse {verification_id, phone_number}
    UserManagementApi-->>Client: Ok(SendRadarSmsChallengeResponse)

    Client->>UserManagementApi: authenticate(RadarSmsChallengeCodeSessionAuthenticateRequest)
    Note right of Client: includes verification_id from above
    UserManagementApi->>WorkOS API: POST /user_management/authenticate
    WorkOS API-->>UserManagementApi: AuthenticationResponse
    UserManagementApi-->>Client: Ok(AuthenticationResponse)

    Note over Client,WorkOS API: create_user — return type change
    Client->>UserManagementApi: create_user(CreateUserParams)
    UserManagementApi->>WorkOS API: POST /user_management/users
    WorkOS API-->>UserManagementApi: UserCreateResponse {radar_auth_attempt_id?}
    UserManagementApi-->>Client: Ok(UserCreateResponse)
    Note right of Client: No User fields (id, email, etc.) returned anymore
Loading

Comments Outside Diff (1)

  1. src/resources/user_management.rs, line 1534-1544 (link)

    P1 Breaking return-type change drops all User fields

    create_user previously returned Result<User, Error>, giving callers access to the new user's id, email, first_name, and every other User field. It now returns Result<UserCreateResponse, Error>, which contains only Option<radar_auth_attempt_id>. Any existing caller that accesses the returned user object (e.g. result?.id) will fail to compile and will also lose access to the created user's data without an additional API call. This warrants a semver-major bump if the crate follows semver.

    Prompt To Fix With AI
    This is a comment left during a code review.
    Path: src/resources/user_management.rs
    Line: 1534-1544
    
    Comment:
    **Breaking return-type change drops all User fields**
    
    `create_user` previously returned `Result<User, Error>`, giving callers access to the new user's `id`, `email`, `first_name`, and every other `User` field. It now returns `Result<UserCreateResponse, Error>`, which contains only `Option<radar_auth_attempt_id>`. Any existing caller that accesses the returned user object (e.g. `result?.id`) will fail to compile and will also lose access to the created user's data without an additional API call. This warrants a semver-major bump if the crate follows semver.
    
    How can I resolve this? If you propose a fix, please make it concise.
Prompt To Fix All With AI
Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
src/resources/user_management.rs:1534-1544
**Breaking return-type change drops all User fields**

`create_user` previously returned `Result<User, Error>`, giving callers access to the new user's `id`, `email`, `first_name`, and every other `User` field. It now returns `Result<UserCreateResponse, Error>`, which contains only `Option<radar_auth_attempt_id>`. Any existing caller that accesses the returned user object (e.g. `result?.id`) will fail to compile and will also lose access to the created user's data without an additional API call. This warrants a semver-major bump if the crate follows semver.

### Issue 2 of 3
src/resources/user_management.rs:2184-2193
**Breaking return-type change drops all MagicAuth fields**

`create_magic_auth` previously returned `Result<MagicAuth, Error>`, giving callers the magic auth record (id, email, expiration, etc.). It now returns `Result<MagicAuthSendMagicAuthCodeAndReturnResponse, Error>`, which only carries `Option<radar_auth_attempt_id>`. Callers that inspect any field on the returned `MagicAuth` will fail to compile after upgrading to this version.

### Issue 3 of 3
tests/user_management_test.rs:3278
**Round-trip tests inline `"{}"` instead of using the newly created fixture files**

`user_create_response.json` (also `magic_auth_send_magic_auth_code_and_return_response.json`) are both `{}`, which is identical to what the tests now inline directly. The fixture files are tracked in `.oagen-manifest.json` and will be maintained by the generator, yet the tests don't use them. Every other round-trip test in this file loads its fixture via `include_str!("fixtures/…")`. The inconsistency means the fixture files serve no purpose, and future additions to the response schema won't be exercised by these tests.

Reviews (1): Last reviewed commit: "chore(generated): add release notes frag..." | Re-trigger Greptile

Comment on lines 2184 to 2193
@@ -2141,7 +2193,7 @@ impl<'a> UserManagementApi<'a> {
&self,

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Breaking return-type change drops all MagicAuth fields

create_magic_auth previously returned Result<MagicAuth, Error>, giving callers the magic auth record (id, email, expiration, etc.). It now returns Result<MagicAuthSendMagicAuthCodeAndReturnResponse, Error>, which only carries Option<radar_auth_attempt_id>. Callers that inspect any field on the returned MagicAuth will fail to compile after upgrading to this version.

Prompt To Fix With AI
This is a comment left during a code review.
Path: src/resources/user_management.rs
Line: 2184-2193

Comment:
**Breaking return-type change drops all MagicAuth fields**

`create_magic_auth` previously returned `Result<MagicAuth, Error>`, giving callers the magic auth record (id, email, expiration, etc.). It now returns `Result<MagicAuthSendMagicAuthCodeAndReturnResponse, Error>`, which only carries `Option<radar_auth_attempt_id>`. Callers that inspect any field on the returned `MagicAuth` will fail to compile after upgrading to this version.

How can I resolve this? If you propose a fix, please make it concise.

.respond_with(
ResponseTemplate::new(200).set_body_string(include_str!("fixtures/user.json")),
)
.respond_with(ResponseTemplate::new(200).set_body_string("{}"))

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Round-trip tests inline "{}" instead of using the newly created fixture files

user_create_response.json (also magic_auth_send_magic_auth_code_and_return_response.json) are both {}, which is identical to what the tests now inline directly. The fixture files are tracked in .oagen-manifest.json and will be maintained by the generator, yet the tests don't use them. Every other round-trip test in this file loads its fixture via include_str!("fixtures/…"). The inconsistency means the fixture files serve no purpose, and future additions to the response schema won't be exercised by these tests.

Prompt To Fix With AI
This is a comment left during a code review.
Path: tests/user_management_test.rs
Line: 3278

Comment:
**Round-trip tests inline `"{}"` instead of using the newly created fixture files**

`user_create_response.json` (also `magic_auth_send_magic_auth_code_and_return_response.json`) are both `{}`, which is identical to what the tests now inline directly. The fixture files are tracked in `.oagen-manifest.json` and will be maintained by the generator, yet the tests don't use them. Every other round-trip test in this file loads its fixture via `include_str!("fixtures/…")`. The inconsistency means the fixture files serve no purpose, and future additions to the response schema won't be exercised by these tests.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

0 participants