feat!(generated): regenerate from spec (5 changes)#380
feat!(generated): regenerate from spec (5 changes)#380workos-sdk-automation[bot] wants to merge 1 commit intomainfrom
Conversation
Greptile SummaryThis is an auto-generated SDK regeneration from an updated OpenAPI spec, introducing org-vs-user-owned API key resource families ( Confidence Score: 4/5Safe to merge; only P2 style findings, no functional defects. All findings are P2 (naming inconsistency on listJWTTemplate, unused CreateUserApiKey model). The rawurlencode hardening, new resource models, fixture updates, and test coverage are all consistent and correct. lib/Service/UserManagement.php (listJWTTemplate naming), lib/Resource/CreateUserApiKey.php (unused in service layer) Important Files Changed
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| ?\WorkOS\RequestOptions $options = null, | ||
| ): \WorkOS\Resource\JWTTemplateResponse { | ||
| $response = $this->client->request( | ||
| method: 'GET', | ||
| path: 'user_management/jwt_template', | ||
| options: $options, | ||
| ); | ||
| return JWTTemplateResponse::fromArray($response); | ||
| } | ||
|
|
||
| /** |
There was a problem hiding this comment.
listJWTTemplate name implies a collection but returns a single object
The method is named listJWTTemplate and its docblock says "Get JWT template", yet it returns a single \WorkOS\Resource\JWTTemplateResponse (not a paginated list or array). The list* prefix is used throughout this SDK for paginated endpoints (e.g. listOrganizationApiKeys, listUserApiKeys). Since this is auto-generated, it's worth raising with the spec owners to rename to getJWTTemplate for consistency and clarity.
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!
| <?php | ||
|
|
||
| declare(strict_types=1); | ||
|
|
||
| // This file is auto-generated by oagen. Do not edit. | ||
|
|
||
| namespace WorkOS\Resource; | ||
|
|
||
| readonly class CreateUserApiKey implements \JsonSerializable | ||
| { | ||
| use JsonSerializableTrait; | ||
|
|
||
| public function __construct( | ||
| /** A descriptive name for the API key. */ | ||
| public string $name, | ||
| /** The ID of the organization the user API key is associated with. The user must have an active membership in this organization. */ | ||
| public string $organizationId, | ||
| /** | ||
| * The permission slugs to assign to the API key. Each permission must be enabled for user API keys. | ||
| * @var array<string>|null | ||
| */ | ||
| public ?array $permissions = null, | ||
| ) { | ||
| } | ||
|
|
||
| public static function fromArray(array $data): self | ||
| { | ||
| return new self( | ||
| name: $data['name'], | ||
| organizationId: $data['organization_id'], | ||
| permissions: $data['permissions'] ?? null, | ||
| ); | ||
| } | ||
|
|
||
| public function toArray(): array | ||
| { | ||
| return [ | ||
| 'name' => $this->name, | ||
| 'organization_id' => $this->organizationId, | ||
| 'permissions' => $this->permissions, | ||
| ]; | ||
| } | ||
| } |
There was a problem hiding this comment.
CreateUserApiKey model is never referenced by the service layer
CreateUserApiKey is generated as a DTO for the create-user-API-key request payload, but UserManagement::createUserApiKey() builds the request body inline with an array_filter([...]) call rather than using this model. The model is dead code from the service's perspective — no SDK method constructs or accepts a CreateUserApiKey instance. If intended only for consumers who want a typed serialization object, it should be consistent with how createOrganizationApiKey is handled (which also has no corresponding model). Worth flagging to the spec/generator team for alignment.
Summary
feat!(api_keys): Refactor API keys for org and user ownership
ApiKeyWithValueandApiKeyListmodels; replaced withOrganizationApiKeyandUserApiKeyfamiliesApiKey.ownerfield type fromApiKeyOwnerto organization-only variantlistOrganizationApiKeys(),createOrganizationApiKey()listUserApiKeys(),createUserApiKey()in UserManagement servicefeat!(user_management): Add user field to membership models and API key management
userfield toUserOrganizationMembershipandOrganizationMembershipmodelsnamefield toProfilemodellistJWTTemplate()method to retrieve JWT templatelistUserApiKeys()andcreateUserApiKey()methods for user API key managementCreateUserApiKeymodel for request payloadsfeat(directory_sync): Add name field to directory user models
namefield toDirectoryUserandDirectoryUserWithGroupsmodelsDsyncUserUpdatedDatato includenamefieldfeat(webhooks): Add support for BYOK key deletion events
VaultByokKeyDeletedandVaultByokKeyDeletedDataevent modelsVaultByokKeyDeletedDataKeyProviderenumADMIN_PORTALvalue to multiple event actor source enums (EventContextActorSource, FlagCreatedContextActorSource, etc.)feat(authentication): Add admin_portal actor source to auth events
ADMIN_PORTALvalue toEventContextActorSourceenumADMIN_PORTALvalue toFlagCreatedContextActorSourceenumADMIN_PORTALvalue toFlagDeletedContextActorSourceenumADMIN_PORTALvalue toFlagRuleUpdatedContextActorSourceenumADMIN_PORTALvalue toFlagUpdatedContextActorSourceenumTriggered by workos/openapi-spec@058a0a4
BEGIN_COMMIT_OVERRIDE
feat!(api_keys): Refactor API keys for org and user ownership
feat!(user_management): Add user field to membership models and API key management
feat(directory_sync): Add name field to directory user models
feat(webhooks): Add support for BYOK key deletion events
feat(authentication): Add admin_portal actor source to auth events
END_COMMIT_OVERRIDE