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@e350eb0

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

[greptile-apps]

Greptile Summary

This PR adds Radar-related user management models and service methods. The main changes are:

• New Radar SMS challenge request and response models.
• New Radar email and SMS challenge authentication request models.
• Radar signal fields on existing user, magic auth, password, code, and standalone assessment models.
• Updated createUser() and createMagicAuth() response models.
• A new createRadarChallenge() service method and related fixtures/tests.

Confidence Score: 3/5

The user management service API needs attention before merge because new Radar-capable models are not fully reachable through the public wrappers.

The changed model surface is broad and mostly generated, but the service layer appears to omit newly added authentication fields and challenge completion entry points.

lib/Service/UserManagement.php

T-Rex Logs

What T-Rex did

• Created a focused PHP repro script to verify authentication field handling and wrapper payloads.
• Attempted to run the PHP repro script but execution was blocked because PHP is not installed in the environment.
• Created a focused Radar challenge repro script to exercise createRadarChallenge and related models.
• Attempted to run the Radar repro script but the PHP binary was not installed, blocking execution.
• Compared pre-change vs post-change radar/auth flow behavior, noting initial errors and later successful outcomes.
• Validated the Radar challenge API surface by showing createRadarChallenge method availability flipped to true and that the POST path and fields behaved as expected.
• Validated the radar challenge request/response flow via logs of a POST to user_management/radar_challenges and a subsequent radar verification ID.
• Model serialization coverage expanded to include radar challenge and authentication-related models, with serialization/deserialization across all cases and no network calls.

_{Ran code and verified through T-Rex}

Comments Outside Diff (2)

1. lib/Service/UserManagement.php, line 72-80 (link)

   Authentication fields dropped
   The generated request models now include signals_id and radar_auth_attempt_id, but the public authenticate wrappers still cannot accept or send them. For example, PasswordSessionAuthenticateRequest serializes both fields while authenticateWithPassword() only builds grant_type, credentials, invitation/IP/device/user-agent. Callers using the service API cannot correlate Radar attempts on password auth; authenticateWithCode() and authenticateWithMagicAuth() have the same mismatch for their new fields.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: lib/Service/UserManagement.php
   Line: 72-80
   
   Comment:
   **Authentication fields dropped**
   The generated request models now include `signals_id` and `radar_auth_attempt_id`, but the public authenticate wrappers still cannot accept or send them. For example, `PasswordSessionAuthenticateRequest` serializes both fields while `authenticateWithPassword()` only builds `grant_type`, credentials, invitation/IP/device/user-agent. Callers using the service API cannot correlate Radar attempts on password auth; `authenticateWithCode()` and `authenticateWithMagicAuth()` have the same mismatch for their new fields.
   
   How can I resolve this? If you propose a fix, please make it concise.

2. General comment

   Claimed Radar::assess SDK method is missing

   • Bug
     • The PR validation claim says Radar::assess should accept optional signals_id/signalsId and send it. Runtime validation on head shows method_exists($radar, 'assess') is false, so callers using the claimed SDK method cannot call it at all. The implementation only exposes Radar::createAttempt, which does accept signalsId and sends signals_id.
   • Cause
     • lib/Service/Radar.php implements the updated Radar risk-assessment contract under createAttempt at the changed method around lines 32-55, but does not provide the claimed assess API surface/alias.
   • Fix
     • Add the claimed Radar::assess(...) method with the same signature/body behavior as createAttempt(...), or update the public SDK contract/documentation and tests to consistently expose createAttempt instead of assess.

   _{Ran code and verified through T-Rex}

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
lib/Service/UserManagement.php:72-80
**Authentication fields dropped**
The generated request models now include `signals_id` and `radar_auth_attempt_id`, but the public authenticate wrappers still cannot accept or send them. For example, `PasswordSessionAuthenticateRequest` serializes both fields while `authenticateWithPassword()` only builds `grant_type`, credentials, invitation/IP/device/user-agent. Callers using the service API cannot correlate Radar attempts on password auth; `authenticateWithCode()` and `authenticateWithMagicAuth()` have the same mismatch for their new fields.

### Issue 2 of 2
lib/Service/UserManagement.php:455
**Challenge flow incomplete**
This doc directs callers to finish the SMS challenge with the `urn:workos:oauth:grant-type:radar-sms-challenge:code` grant type, and the PR adds `RadarSmsChallengeCodeSessionAuthenticateRequest`, but `UserManagement` exposes no authenticate method for that grant. After calling `createRadarChallenge()`, SDK users cannot complete the documented SMS challenge flow through the service API; the email challenge request model is similarly unreachable.

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

[greptile-apps]

Challenge flow incomplete
This doc directs callers to finish the SMS challenge with the urn:workos:oauth:grant-type:radar-sms-challenge:code grant type, and the PR adds RadarSmsChallengeCodeSessionAuthenticateRequest, but UserManagement exposes no authenticate method for that grant. After calling createRadarChallenge(), SDK users cannot complete the documented SMS challenge flow through the service API; the email challenge request model is similarly unreachable.

Prompt To Fix With AI

This is a comment left during a code review.
Path: lib/Service/UserManagement.php
Line: 455

Comment:
**Challenge flow incomplete**
This doc directs callers to finish the SMS challenge with the `urn:workos:oauth:grant-type:radar-sms-challenge:code` grant type, and the PR adds `RadarSmsChallengeCodeSessionAuthenticateRequest`, but `UserManagement` exposes no authenticate method for that grant. After calling `createRadarChallenge()`, SDK users cannot complete the documented SMS challenge flow through the service API; the email challenge request model is similarly unreachable.

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