feat(generated)!: regenerate from spec (13 changes)

[workos-sdk-automation]

Summary

feat(authorization)!: Rename RoleAssignment to UserRoleAssignment

• Renamed RoleAssignment model to UserRoleAssignment
• Renamed RoleAssignmentResource to UserRoleAssignmentResource
• Added organization_membership_id field to UserRoleAssignment
• Updated list_role_assignments() return type to UserRoleAssignment
• Updated assign_role() return type to UserRoleAssignment

feat(authorization)!: Consolidate order enums to PaginationOrder

• Removed service-specific order enums: AuthorizationOrder, PermissionsOrder
• Replaced with unified PaginationOrder enum for all list operations
• Updated all authorization list method signatures to use PaginationOrder
• Breaking change for code explicitly referencing old enum types

feat(authorization): Add new role assignment listing endpoints

• Added list_role_assignments_for_resource() method
• Added list_role_assignments_for_resource_by_external_id() method
• Returns paginated list of UserRoleAssignment objects for a resource

feat(api_keys)!: Separate organization and user API key types

• Created OrganizationApiKey class to replace generic ApiKey usage
• Created OrganizationApiKeyWithValue to replace ApiKeyWithValue
• Renamed ApiKeyWithValueOwner to OrganizationApiKeyWithValueOwner
• Updated list_organization_api_keys() return type to OrganizationApiKey
• Updated create_organization_api_key() return type to OrganizationApiKeyWithValue

feat(user_management): Add user API key management

• Added UserApiKey model to represent user-scoped API keys
• Added UserApiKeyWithValue model for creation responses
• Added UserApiKeyOwner and related owner models
• Added list_user_api_keys() method to list user API keys by user ID
• Added create_user_api_key() method to create new user API keys
• Added CreateUserApiKey request model

feat(user_management)!: Consolidate order enums to PaginationOrder

• Removed service-specific order enums: UserManagementUsersOrder, UserManagementInvitationsOrder, UserManagementOrganizationMembershipOrder, UserManagementOrganizationMembershipGroupsOrder, UserManagementUsersFeatureFlagsOrder, UserManagementUsersAuthorizedApplicationsOrder, UserManagementMultiFactorAuthenticationOrder
• Replaced with unified PaginationOrder enum for all list operations
• Updated all user management list method signatures to use PaginationOrder

feat(user_management): Add user field to membership and organization membership

• Added user field to UserOrganizationMembership (embedded User object)
• Added user field to UserOrganizationMembershipBaseListData (embedded User object)
• Added user field to OrganizationMembership (embedded User object)

feat(user_management): Add get JWT template endpoint

• Added list_jwt_template() method to retrieve current JWT template configuration

feat(directory_sync): Add name field to directory users

• Added name field to DirectoryUser model
• Added name field to DirectoryUserWithGroups model
• Added name field to DsyncUserUpdatedData model
• Updated deprecation notice for groups field in DirectoryUserWithGroups

feat(sso): Add name field to SSO profile

• Added name field to Profile model to provide full name when available

feat(vault)!: Add BYOK key deleted event and consolidate key provider enum

• Added VaultByokKeyDeleted event model for vault.byok_key.deleted events
• Added VaultByokKeyDeletedData model containing organization_id and key_provider
• Renamed VaultByokKeyVerificationCompletedDataKeyProvider to VaultByokKeyProvider
• Unified key provider enum for use across multiple BYOK key event types

feat(types)!: Consolidate pagination order enums

• Removed 16 service-specific order enum files (ApplicationsOrder, ConnectionsOrder, DirectoriesOrder, DirectoryGroupsOrder, DirectoryUsersOrder, EventsOrder, FeatureFlagsOrder, GroupsOrder, OrganizationsOrder, OrganizationsApiKeysOrder, OrganizationsFeatureFlagsOrder, WebhooksOrder, and related user management variants)
• Created unified PaginationOrder enum with values: NORMAL, DESC, ASC
• All list operations now reference the single PaginationOrder type

feat(events): Add admin_portal source to event context actor

• Added ADMIN_PORTAL = "admin_portal" value to EventContextActorSource enum
• Allows events to be tagged with admin portal as the source

Triggered by workos/openapi-spec@a06e54d

BEGIN_COMMIT_OVERRIDE
feat(authorization)!: Rename RoleAssignment to UserRoleAssignment
feat(authorization)!: Consolidate order enums to PaginationOrder
feat(authorization): Add new role assignment listing endpoints
feat(api_keys)!: Separate organization and user API key types
feat(user_management): Add user API key management
feat(user_management)!: Consolidate order enums to PaginationOrder
feat(user_management): Add user field to membership and organization membership
feat(user_management): Add get JWT template endpoint
feat(directory_sync): Add name field to directory users
feat(sso): Add name field to SSO profile
feat(vault)!: Add BYOK key deleted event and consolidate key provider enum
feat(types)!: Consolidate pagination order enums
feat(events): Add admin_portal source to event context actor
END_COMMIT_OVERRIDE

[greptile-apps]

Greptile Summary

This is a large auto-generated PR (94 files) that regenerates the WorkOS Ruby SDK from an updated OpenAPI spec across 13 feature areas.

• Authorization: RoleAssignment renamed to UserRoleAssignment (adds organization_membership_id), two new listing endpoints for role assignments on resources, all order params migrated to the new unified PaginationOrder enum.
• API Keys: Generic ApiKey split into OrganizationApiKey/OrganizationApiKeyWithValue and a new parallel UserApiKey/UserApiKeyWithValue hierarchy with corresponding list_user_api_keys and create_user_api_key methods on UserManagement.
• Types consolidation: 16 service-specific order enums removed and replaced by a single WorkOS::Types::PaginationOrder; VaultByokKeyProvider unified; EventContextActorSource::ADMIN_PORTAL added.
• Model field additions: name added to DirectoryUser, DirectoryUserWithGroups, DsyncUserUpdatedData, and Profile; user embedded in membership models; list_jwt_template endpoint added to retrieve JWT template configuration.

Confidence Score: 4/5

The change is safe to merge — all new endpoints are additive, breaking renames are intentional and consistent with the spec, and existing behaviour is preserved.

The bulk of the change is mechanical spec-driven generation that is well-tested. Two non-blocking observations: list_jwt_template carries a 'list' prefix yet returns a single JWTTemplateResponse object, which diverges from every other list_* method in the SDK and could confuse callers. Additionally, UserApiKeyOwner is aliased inside lib/workos/api_keys/ while the model consuming it (UserApiKey) lives in lib/workos/user_management/, breaking the directory-per-module convention followed everywhere else.

lib/workos/user_management.rb (list_jwt_template naming) and lib/workos/api_keys/user_api_key_owner.rb (cross-directory alias)

Important Files Changed

Filename	Overview
lib/workos/user_management.rb	Added list_user_api_keys, create_user_api_key, and list_jwt_template methods; removed 7 service-specific order enums in favour of PaginationOrder; added user field to membership types. The new list_jwt_template method is misnamed — it returns a singleton JWTTemplateResponse, not a list.
lib/workos/authorization.rb	Renamed RoleAssignment → UserRoleAssignment, added list_role_assignments_for_resource and list_role_assignments_for_resource_by_external_id methods, migrated all order params to PaginationOrder. Logic looks correct.
lib/workos/api_keys.rb	Replaced generic ApiKey with OrganizationApiKey/OrganizationApiKeyWithValue, reordered create_validation and delete_api_key to the bottom. No logic changes to existing behaviour.
lib/workos/api_keys/user_api_key_owner.rb	Defines UserApiKeyOwner as a type alias for UserApiKeyCreatedDataOwner, but is placed in api_keys/ while all consuming user API key models live in user_management/. Works at runtime but is organisationally inconsistent.
lib/workos/types/pagination_order.rb	New unified enum replacing 16 service-specific order enums with NORMAL, DESC, ASC constants. Clean consolidation.
lib/workos/user_management/user_api_key.rb	New UserApiKey model mirroring OrganizationApiKey structure; delegates owner construction to WorkOS::UserApiKeyOwner.
lib/workos/authorization/user_role_assignment.rb	New model replacing RoleAssignment; adds organization_membership_id field and nested UserRoleAssignmentResource hydration.
lib/workos/vault/vault_byok_key_deleted.rb	New event model for vault.byok_key.deleted; hydrates VaultByokKeyDeletedData and EventContext. Straightforward addition.

Class Diagram

%%{init: {'theme': 'neutral'}}%%
classDiagram
    class UserRoleAssignment {
        +object
        +id
        +organization_membership_id
        +role : SlimRole
        +resource : UserRoleAssignmentResource
        +created_at
        +updated_at
    }
    class OrganizationApiKey {
        +object
        +id
        +owner : OrganizationApiKeyOwner
        +name
        +obfuscated_value
        +permissions[]
        +created_at
        +updated_at
    }
    class OrganizationApiKeyWithValue {
        +value
    }
    class UserApiKey {
        +object
        +id
        +owner : UserApiKeyOwner
        +name
        +obfuscated_value
        +permissions[]
        +created_at
        +updated_at
    }
    class UserApiKeyWithValue {
        +value
    }
    class PaginationOrder {
        +NORMAL
        +DESC
        +ASC
    }
    OrganizationApiKey <|-- OrganizationApiKeyWithValue
    UserApiKey <|-- UserApiKeyWithValue
    PaginationOrder ..> OrganizationApiKey : order param
    PaginationOrder ..> UserApiKey : order param
    PaginationOrder ..> UserRoleAssignment : order param

Loading

Comments Outside Diff (1)

1. lib/workos/api_keys/user_api_key_owner.rb, line 1-7 (link)

   UserApiKeyOwner alias placed in the wrong namespace directory

   WorkOS::UserApiKeyOwner is an alias for UserApiKeyCreatedDataOwner but lives in lib/workos/api_keys/ while the type that consumes it — WorkOS::UserApiKey — is in lib/workos/user_management/. All other user API key owner types (UserApiKeyCreatedDataOwner, UserApiKeyWithValueOwner, UserApiKeyRevokedDataOwner) are in the user_management/ directory. This cross-directory dependency is invisible from the user_management/ side and breaks the established convention that each sub-module's supporting types live alongside the model that uses them.

_{Reviews (1): Last reviewed commit: "feat(generated)!: regenerate from spec (..." | Re-trigger Greptile}

[greptile-apps]

Misleading list_ prefix for a singleton resource

list_jwt_template performs a GET on /user_management/jwt_template and returns a single JWTTemplateResponse, not a paginated collection. Every other list_* method in this SDK returns a WorkOS::Types::ListStruct. A caller following the naming convention would reasonably expect to iterate over results, but there are none to iterate — calling .data or .each on the returned object will fail. The companion write method is correctly named update_jwt_template, so a consistent read name would be get_jwt_template.