You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When retrieving users from Notion, the result that comes back is a PaginatedList<User> result. By default, the limit is 100 items. For most small organizations this is fine. However if you have more than 100 users, the result will show that more records are available, along with a start cursor to use in the next request. The IUsersClient.ListAsync() method does not provide a parameter to supply that start cursor to request the next page of results. Thus if you want to get ALL the users, you can only get the first 100 when using the methods available.
Describe the solution you'd like
I would like to see an update to the IUsersClient.ListAsync method to include an optional parameter to supply a start cursor. This would be enough to make it easy to get multiple pages of results, and wouldn't break existing implementations because users could still call the method without a parameter and get the same behavior.
Though a more complete solution that's more "true to the API" would be a parameters object that includes both the page size as well as the start cursor.
Describe alternatives you've considered
I have found a workaround that uses the Notion.Net RestClient which works. This was based on the source code used for the ListAsync method, with some added logic to update the query string as needed. This works as an extension method to the Notion Client.
public static async Task<PaginatedList<User>> ListUsersPagedAsync(this INotionClient notionClient, string? startCursor = null)
{
var queryParams = new Dictionary<string, string>();
if (!string.IsNullOrWhiteSpace(startCursor))
{
queryParams["start_cursor"] = startCursor;
}
var result = await notionClient.RestClient.GetAsync<PaginatedList<User>>(ApiEndpoints.UsersApiUrls.List(), queryParams);
return result;
}
In my own implementation I have a loop that makes subsequent calls and updates the start cursor for each call, much like the way you would use the IDatabasesClient.QueryAsync method to get multiple pages.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
When retrieving users from Notion, the result that comes back is a
PaginatedList<User>
result. By default, the limit is 100 items. For most small organizations this is fine. However if you have more than 100 users, the result will show that more records are available, along with a start cursor to use in the next request. TheIUsersClient.ListAsync()
method does not provide a parameter to supply that start cursor to request the next page of results. Thus if you want to get ALL the users, you can only get the first 100 when using the methods available.Link to the API reference: https://developers.notion.com/reference/get-users
Describe the solution you'd like
I would like to see an update to the
IUsersClient.ListAsync
method to include an optional parameter to supply a start cursor. This would be enough to make it easy to get multiple pages of results, and wouldn't break existing implementations because users could still call the method without a parameter and get the same behavior.Though a more complete solution that's more "true to the API" would be a parameters object that includes both the page size as well as the start cursor.
Describe alternatives you've considered
I have found a workaround that uses the Notion.Net RestClient which works. This was based on the source code used for the
ListAsync
method, with some added logic to update the query string as needed. This works as an extension method to the Notion Client.In my own implementation I have a loop that makes subsequent calls and updates the start cursor for each call, much like the way you would use the
IDatabasesClient.QueryAsync
method to get multiple pages.The text was updated successfully, but these errors were encountered: