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

[workos-sdk-automation]

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 (#513)
fix(user_management): Update user management API surface (#513)
END_COMMIT_OVERRIDE

[greptile-apps]

Greptile Summary

This PR updates the generated Ruby SDK surface for Radar and User Management. The main changes are:

• Adds Radar challenge request and response models.
• Adds Radar correlation fields such as signals_id and radar_auth_attempt_id to authentication, magic auth, user creation, and Radar attempt requests.
• Updates User Management create-user and magic-auth response models.
• Adds the /user_management/radar_challenges SDK method.
• Regenerates RBI signatures, manifest entries, changelog content, and round-trip tests.

Confidence Score: 5/5

The generated SDK updates appear safe to merge, with no code issues identified.

The changes are generated model, endpoint, RBI, changelog, and round-trip test updates matching the described API surface expansion.

T-Rex Logs

What T-Rex did

• The initial test run revealed base rejection of the new contract surface with unknown keyword errors for authenticate, user, and magic_auth fields and a NoMethodError for create_radar_challenge; the head then serialized the new request bodies and posted to the expected paths, surfacing a mismatch where WorkOS::MagicAuthSendMagicAuthCodeAndReturnResponse is returned instead of WorkOS::UserCreateResponse and authentication_factor_id is missing from the response.
• The generated-models artifacts show the before state with missing/new contract surface constants and missing readers, and the after state exits with a clean RESULT SUCCESS and all requested constants present and initialized from a hash.
• The radar-signals artifacts show the before run failing with an unknown signals_id keyword and no model_signals_id accessor, and the after run posting to /radar/attempts with signals_id set, returning 201 and model_signals_id_value matching the posted id.

_{Ran code and verified through T-Rex}

Comments Outside Diff (2)

1. General comment

   create_user returns MagicAuthSendMagicAuthCodeAndReturnResponse instead of the documented UserCreateResponse class

   • Bug
     • The PR contract requires create_user to return WorkOS::UserCreateResponse including radar_auth_attempt_id. The head runtime scenario posted the correct body to /user_management/users and exposed radar_auth_attempt_id, but the instantiated response object's class was WorkOS::MagicAuthSendMagicAuthCodeAndReturnResponse, not WorkOS::UserCreateResponse. This is caused by UserCreateResponse being a constant alias, so callers inspecting the class or relying on a distinct response model do not receive the documented class.
   • Cause
     • lib/workos/user_management/user_create_response.rb:6 aliases UserCreateResponse to MagicAuthSendMagicAuthCodeAndReturnResponse, and lib/workos/user_management.rb:772 constructs that alias, producing an object whose runtime class remains WorkOS::MagicAuthSendMagicAuthCodeAndReturnResponse.
   • Fix
     • Define WorkOS::UserCreateResponse as its own response model class with the same relevant attributes, including radar_auth_attempt_id, rather than aliasing it to MagicAuthSendMagicAuthCodeAndReturnResponse.

   _{Ran code and verified through T-Rex}

2. General comment

   SendRadarSmsChallengeResponse drops authentication_factor_id from radar challenge responses

   • Bug
     • The PR contract requires create_radar_challenge to return WorkOS::SendRadarSmsChallengeResponse with authentication_factor_id and verification_id. The head runtime scenario posted the expected body to /user_management/radar_challenges and returned WorkOS::SendRadarSmsChallengeResponse with verification_id, but response.authentication_factor_id was not available even though the fake API response included authentication_factor_id.
   • Cause
     • lib/workos/user_management/send_radar_sms_challenge_response.rb:7-20 maps and exposes only verification_id and phone_number; authentication_factor_id is missing from HASH_ATTRS, attr_accessor, and initialize assignment.
   • Fix
     • Add authentication_factor_id to SendRadarSmsChallengeResponse HASH_ATTRS, attr_accessor list, and initialize assignment so the SDK preserves the API field.

   _{Ran code and verified through T-Rex}

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