Allow for same param name but different contextual usage#520
Merged
gjtorikian merged 3 commits intomainfrom Jan 20, 2026
Merged
Allow for same param name but different contextual usage#520gjtorikian merged 3 commits intomainfrom
gjtorikian merged 3 commits intomainfrom
Conversation
The param provided by users is `user_id`/ `group_id` / `directory_id`; this is expected as `user` / `group` / `directory` by the API. BUT, paginating through these endpoints requires the `*_id` version of these params, so we need to add some kind of translation to change the value, depending on context
Contributor
Greptile SummaryThis PR fixes a parameter naming mismatch between the SDK and API by introducing a translation layer at the HTTP request boundary. The SDK uses Pythonic parameter names (
Confidence Score: 5/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant User
participant DirectorySync
participant PrepareParams as _prepare_request_params()
participant HTTPClient
participant WorkOSAPI as WorkOS API
participant ListResource as WorkOSListResource
User->>DirectorySync: list_users(directory_id="dir_123")
DirectorySync->>DirectorySync: Create list_params with directory_id
DirectorySync->>PrepareParams: _prepare_request_params(list_params)
PrepareParams->>PrepareParams: Translate directory_id → directory
PrepareParams-->>DirectorySync: request_params with "directory"
DirectorySync->>HTTPClient: request(params=request_params)
HTTPClient->>WorkOSAPI: GET /directory_users?directory=dir_123
WorkOSAPI-->>HTTPClient: Response with users
HTTPClient-->>DirectorySync: response
DirectorySync->>ListResource: Create WorkOSListResource(list_args=list_params)
Note over ListResource: list_args contains directory_id for pagination
User->>ListResource: Iterate (pagination)
ListResource->>DirectorySync: list_users(directory_id="dir_123", after="cursor")
DirectorySync->>PrepareParams: _prepare_request_params(list_params)
PrepareParams-->>DirectorySync: request_params with "directory"
DirectorySync->>HTTPClient: request(params=request_params)
HTTPClient->>WorkOSAPI: GET /directory_users?directory=dir_123&after=cursor
WorkOSAPI-->>HTTPClient: Next page
HTTPClient-->>ListResource: response
|
nicknisi
approved these changes
Jan 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
As #519 notes, #512 corrected one problem and introduced another.
The param provided by users through the SDK is
user_id/group_id/directory_id; the API accepts parameters asuser/group/directoryby the API, without the suffix. What I misunderstood was that pagination actually requires the*_idversion of these parameters, so while #512 fixed pagination (by using*_id), it went ahead and broke regular API calls (by using the incorrect, suffixless parameters).Makes sense? Yeah, I had to re-read everything a few times myself to understand the difference in usage. The key is in these lines (repeated throughout several API resources, I'm just picking one):
The request uses
list_params, and then the paginationWorkOSListResourceuseslist_paramsagain.To solve this, I added a function to translate the parameter name, depending on the context it's used. Essentially, this branch keeps the
*_idnames internally for pagination, then renames to the suffixless version them right before the HTTP call.Documentation
Does this require changes to the WorkOS Docs? E.g. the API Reference or code snippets need updates.
If yes, link a related docs PR and add a docs maintainer as a reviewer. Their approval is required.