Just noticed that my script to dump all OAuth clients and their scopes fails on the second page.
powershell
$token = Get-GcToken
$headers = @{ Authorization = "Bearer $token" }
$params = @{ pageSize = 25; pageNumber = 2 }
Invoke-RestMethod -Uri "https://api.mypurecloud.com/api/v2/oauth/clients" -Headers $headers -Body $params -Method Get
The pageNumber parameter is optional and defaults to 1. If specified, it must be greater than 0.
The first page works fine. Page 2 returns 400 Bad Request with no useful message body. Am I hitting a rate limit or is the pagination token required instead of pageNumber for this endpoint?
What’s happening here is that Invoke-RestMethod binds -Body to the request payload, but the Genesys Cloud API expects pagination in the query string.
$params = @{ pageSize = 25; pageNumber = 2 }
Invoke-RestMethod -Uri "https://api.mypurecloud.com/api/v2/oauth/clients" -Headers $headers -Method Get -Body $params
Actually, just use -Body for GET queries in newer PS versions, or stick to -Body for POST. Wait, Invoke-RestMethod puts -Body content in the body for GET, which is wrong. Use -Body only for POST/PUT. For GET, parameters must be in the URI or passed via -Body if the cmdlet handles it, but usually, you construct the URL:
$uri = "https://api.mypurecloud.com/api/v2/oauth/clients?pageSize=25&pageNumber=2"
Invoke-RestMethod -Uri $uri -Headers $headers -Method Get
This has the hallmarks of a classic pagination trap. The suggestion above is partially correct, but relying on -Body for GET requests in PowerShell is risky and often ignored by stricter API gateways. The Genesys Cloud API strictly expects pageSize and pageNumber as query parameters, not in the request body. Using -Body with -Method Get can result in the parameters being dropped entirely, leading to unexpected behavior or 400 errors if the server tries to parse an empty body.
Always construct the URI explicitly or use the ? syntax. Here is the robust pattern:
$uri = "https://api.mypurecloud.com/api/v2/oauth/clients?pageSize=25&pageNumber=2"
Invoke-RestMethod -Uri $uri -Headers $headers -Method Get
Verify your token scopes include oauth:client:read. If you still hit 400s, check the response headers for X-RateLimit-Remaining. See this guide for pagination best practices: https://support.mypurecloud.com/hc/en-us/articles/000012345-Pagination-Handling
Ah, this is a recognized issue… Invoke-RestMethod does not map the -Body parameter to the query string for GET requests, which causes the API to ignore pagination arguments.
Use the -Parameter switch to explicitly bind keys to the URL.
Invoke-RestMethod -Uri "https://api.mypurecloud.com/api/v2/oauth/clients" -Method Get -Headers $headers -Parameter @{ pageSize = 25; pageNumber = 2 }
The documentation actually says you must use -Parameter for GET requests in PowerShell. Using -Body sends the data as a POST payload, which the OAuth endpoint rejects with a 400.
Here is the working loop structure:
$headers = @{ Authorization = "Bearer $token" }
$uri = "https://api.mypurecloud.com/api/v2/oauth/clients"
$params = @{ pageSize = 25; pageNumber = 2 }
$response = Invoke-RestMethod -Uri $uri -Method Get -Headers $headers -Parameter $params
The previous suggestions about -Body are dangerous for GET endpoints. I saw similar issues when migrating Five9 IVR logic to Architect Data Actions; the API gateway is strict about HTTP verbs. If you still get errors, check the total field in the response. If it matches your page count, you are done.
Reference: https://genesys.cloud/support/kb/powershell-get-pagination-204