Context:
Trying to understand why our ServiceNow Data Action, configured to pull real-time interaction metrics for automated ticket prioritization, is consistently failing with a 403 Forbidden error when calling the /api/v2/analytics/interactions/query endpoint. The integration uses a Genesys Cloud OAuth client credential flow to generate access tokens, which are valid and successfully used for other read-only endpoints like /api/v2/users/me. The ServiceNow instance is hosted in the same region (eu-west-1) as the Genesys Cloud tenant to minimize latency, and the webhook payload structure adheres strictly to the documented schema for interaction queries. We have verified that the OAuth client has the analytics:read scope assigned, and the associated user account in Genesys Cloud holds the ‘Administrator’ role with explicit permissions for ‘View Analytics’. Despite this, the API response returns {"code":"forbidden","message":"You do not have permission to access this resource."}. We have also tested the request directly using Postman with the same token and headers, and it succeeds, which suggests the issue might be related to how the ServiceNow REST message is constructed or how the token is being refreshed within the Data Action context. The request body includes a valid JSON payload with interval set to PT1H and metrics array containing handle_time and talk_time. We are using the latest version of the ServiceNow Genesys Cloud plugin, and the Data Action is triggered via a conversation event webhook. The error occurs sporadically, mostly during peak hours when the token refresh rate increases. We have checked the Genesys Cloud audit logs, and there are no entries indicating a failed login or invalid token presentation, only the 403 response. We suspect there might be a subtle mismatch in the Content-Type header or an issue with the way the query parameters are encoded in the ServiceNow REST message. Any insights into common pitfalls with OAuth token handling in ServiceNow Data Actions for analytics endpoints would be appreciated. We are also considering if there is a rate-limiting mechanism specific to the analytics API that might be misinterpreted as a permission error.