Description
The generated UserServiceMachine request model does not expose accessTokenType, although current ZITADEL User Service V2 supports setting it when creating or updating a machine user.
This prevents Python SDK users from requesting JWT access tokens. ZITADEL otherwise defaults new machine users to opaque bearer tokens.
The SDK already contains:
- UserServiceAccessTokenType
- ACCESS_TOKEN_TYPE_BEARER
- ACCESS_TOKEN_TYPE_JWT
- access_token_type on the UserServiceMachineUser response model
However, the corresponding request model only contains name and description.
Environment
- zitadel_client==4.1.8
- Python 3.14.6
- This appears to be a generated-schema issue and is not Python-version-specific.
Reproduction
from zitadel_client.models import (
UserServiceAccessTokenType,
UserServiceMachine,
)
machine = UserServiceMachine(
name="example-client",
accessTokenType=UserServiceAccessTokenType.ACCESS_TOKEN_TYPE_JWT,
)
print(machine.model_dump(by_alias=True, exclude_none=True))Actual output:
{"name": "example-client"}The unrecognised accessTokenType input is silently discarded.
Consequently, using this model through UserServiceCreateUserRequest cannot send:
{
"machine": {
"name": "example-client",
"accessTokenType": "ACCESS_TOKEN_TYPE_JWT"
}
}The same UserServiceMachine model is used by UserServiceUpdateUserRequest, so updating the access-token type is also unavailable.
Expected behaviour
UserServiceMachine should expose a field equivalent to:
access_token_type: UserServiceAccessTokenType | None = Field(
default=None,
alias="accessTokenType",
)Serializing a create or update request should preserve the selected access-token type.
Upstream context
The missing API capability was reported in:
It was added to the core User Service V2 protobuf in:
The current protobuf contains access_token_type on the nested machine messages for both CreateUserRequest and UpdateUserRequest, but the Python SDK request model still reflects the older schema.
Suggested resolution
Please regenerate the Python SDK against a current ZITADEL core schema and add a serialization test confirming that accessTokenType is included in create and update machine-user requests.
Description
The generated UserServiceMachine request model does not expose accessTokenType, although current ZITADEL User Service V2 supports setting it when creating or updating a machine user.
This prevents Python SDK users from requesting JWT access tokens. ZITADEL otherwise defaults new machine users to opaque bearer tokens.
The SDK already contains:
However, the corresponding request model only contains name and description.
Environment
Reproduction
Actual output:
{"name": "example-client"}The unrecognised accessTokenType input is silently discarded.
Consequently, using this model through UserServiceCreateUserRequest cannot send:
{ "machine": { "name": "example-client", "accessTokenType": "ACCESS_TOKEN_TYPE_JWT" } }The same UserServiceMachine model is used by UserServiceUpdateUserRequest, so updating the access-token type is also unavailable.
Expected behaviour
UserServiceMachine should expose a field equivalent to:
Serializing a create or update request should preserve the selected access-token type.
Upstream context
The missing API capability was reported in:
It was added to the core User Service V2 protobuf in:
The current protobuf contains access_token_type on the nested machine messages for both CreateUserRequest and UpdateUserRequest, but the Python SDK request model still reflects the older schema.
Suggested resolution
Please regenerate the Python SDK against a current ZITADEL core schema and add a serialization test confirming that accessTokenType is included in create and update machine-user requests.