UserServiceMachine request model is missing accessTokenType supported by User Service V2
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 72/100
Research direction
Locate the generated UserServiceMachine request model and the UserServiceCreateUserRequest and UserServiceUpdateUserRequest models, then inspect how the existing UserServiceAccessTokenType fields are represented. Regenerate the Python SDK against the current schema and add serialization coverage showing that accessTokenType is preserved in both create and update machine-user requests.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Python
- Stars
- 16
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from zitadel/client-python
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
zitadel/client-python#125 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 52/100
zitadel/client-python#99 ·
-
Release SDK for V5 Open
zitadel/client-python#80 · 1 assignee ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
zitadel/client-python#78 ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
zitadel/client-python#66 · 1 comment · 4 reactions ·
All issues in zitadel/client-python
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
syfoud/Simulated_Scepter#172 ·
-
A cancelled tests run makes the coverage comment workflow fail and reports it as a red check on main Openarea: ci bug perceived difficulty: 3
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Nitjsefnie-Harness-Commons/daedalus#921 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
EleutherAI/lm-evaluation-harness#4207 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
ClickHouse/clickhouse-connect#1057 ·