The flow is supposed to kick off agent screen capture the moment a transfer hits the wrap-up stage. We’ve got a SNIPPET action wired to a REST Proxy endpoint that hits /api/v2/recordings/screen. The proxy handles interaction metadata fetches just fine, but the moment we POST the recording config, the gateway throws a 403 Forbidden with {"error":"access_denied","code":"INSUFFICIENT_PRIVILEGES"}. The script role definitely has recording:write and interaction:write checked in the admin console.
Walking through the payload construction, the SNIPPET builds a JSON object like {"interactionId": interaction.id, "type": "screen", "settings": {"captureKeystrokes": false}}. I’ve been logging the raw output before the proxy call, and the structure looks clean. Console shows the proxy receives it, but the upstream CXone service rejects it. Maybe the interactionId needs to be the conversationId instead? Or perhaps the REST Proxy is stripping the Authorization header when it tunnels to the recording service.
Tried swapping to interaction.conversationId and the error shifts to a 422 Unprocessable Entity complaining about session_context missing. That’s weird because the docs say screen recording inherits the active agent context automatically. The flow runs in the gb-1 region, CXone platform version 23.4.2. Studio is v2.
Here is the exact SNIPPET mapping block:
let recPayload = {
interactionId: context.data.attributes.interaction_id,
type: "screen",
settings: { captureKeystrokes: false, includeSystemTray: true }
};
return JSON.stringify(recPayload);
The proxy response header shows x-nice-request-id: 8f4a2c1b-99d0-4e8a-b1f3-22c4d5e6a789. Curling the same endpoint with a service account token works instantly. The proxy is doing jack all with the scope handoff, so the recording service never sees a valid agent token.
Checking the audit logs now, it looks like the SNIPPET execution environment is sandboxed and drops the OAuth scope before hitting the proxy. Forcing the proxy to inherit the flow’s runtime token instead of falling back to the default app credentials seems like the only path forward. The docs barely mention token inheritance for SNIPPET-to-proxy handoffs, so I’m just staring at the raw header dump trying to spot where the scope gets stripped.