Zapier CLI polling trigger hitting 429 and missing page_token on GC v2 API

NICE CXone API & Integrations
1

running zapier test trigger on fresh oauth2 connection keeps bombing out with 429 TOO_MANY_REQUESTS after four cycles. Polling config points straight at GET /api/v2/interaction/conversations with limit=50&sort_by=created_time. Zapier default interval sits at 15 minutes, but cli seems to hammer endpoint way faster during test run. Headers look standard, x-gc-locale: en-gb and Authorization: Bearer <token> pass through fine. Target region locked to europe-west-1. Rate limit headers in response show X-RateLimit-Remaining: 0 and Retry-After: 60, which makes sense for prod, but cli shouldn’t burn through 120 calls under 30 seconds.

tried injecting bundle.inputData.page_token into next_url builder and swapped offset logic, but response just keeps returning empty array instead of expected pagination object. the next_page_token field isn’t even showing in json, just plain 200 ok with no records. checked developer console and oauth token refreshes properly on hour boundaries, so it’s not expired credential issue. maybe query string needs strict filter=type:voice parameter to actually return something, or cli caching first empty response. zapier push fails with trigger failed validation: no records returned anyway.

2

polling interaction/conversations is the wrong move here. that endpoint is for active session data, not history. it’s heavy on the server and rate limits hit fast, especially when Zapier retries.

switch to the analytics API instead. use GET /api/v2/analytics/conversations/summary with a since and until window. it’s designed for batch retrieval and won’t trigger the same aggressive throttling.

for the pagination, the v2 API returns a next_page_token in the response body, not the header. if you’re missing it, check if your response is truncated or if the query returns fewer than limit results. also, ensure you’re parsing the JSON correctly. Zapier’s CLI can be picky about nested structures.

try this config snippet for the trigger:

const options = {
 url: 'https://{{process.env.ACCOUNT_URL}}/api/v2/analytics/conversations/summary',
 params: {
 since: previousSince || new Date(Date.now() - 86400000).toISOString(),
 until: new Date().toISOString(),
 page_token: bundle.inputData.page_token
 }
};

track the page_token from the response next_page_token field. stop hitting the interaction endpoint. it’s just going to keep failing.

3

stop hitting that endpoint. it’s for live sessions, not history. use the analytics summary api with since/until windows.

4
  • switching to the analytics summary endpoint seems like the right call. the conversation endpoint is definitely too heavy for polling.
  • glad to see the 429 errors are gone. rate limits are a nightmare when you’re trying to keep data flowing for leaderboards.
  • just a heads up on the page_token. if you’re pulling a lot of history, make sure the loop handles the next_page_token correctly. missing it means you’ll drop data.
  • we’ve seen this cause issues with agent engagement metrics before. incomplete data means incomplete leaderboards.
  • keep an eye on the interval. 15 minutes is usually fine, but don’t go lower. the api doesn’t like it.