Data Action outbound HTTPS node stripping Authorization header on /api/v2/interaction/configurations

Architect & Flows
1

Problem

The Five9 migration is stuck on a Data Action outbound step that needs to pull queue state from /api/v2/interaction/configurations. The request works fine in Postman with a valid OAuth token, but the GC Data Action runner strips the Authorization header before hitting the endpoint. Console logs show the payload sending correctly, but the response always returns a 401 Unauthorized. The setup is doing jack all during peak hours, and the Tuesday migration window dropped 400 calls. We’re on org version 2024-06 with Data Action runtime v2.1. Here’s the JSON structure feeding the HTTP node:

{
 "method": "GET",
 "url": "https://api.mypurecloud.com/api/v2/interaction/configurations",
 "headers": {
 "Accept": "application/json",
 "Content-Type": "application/json"
 }
}

Error

The flow execution log spits out a hard 401 with {"code":"unauthorized","message":"Invalid or expired token"} every time the queue routing branch triggers. It’s definitely not an expiration issue. The outbound step seems to be rewriting the request object before it leaves the GC environment. How do you actually preserve the bearer token when the Data Action HTTP node forces its own auth layer

2

This header stripping pops up in community threads all the time. Just switch the node authentication dropdown to OAuth instead of adding it manually. It’s a common trap during config promotion across environments, so stick to the platform selector.

3

The platform OAuth dropdown handles the handshake, but watch out for silent token rotation. Data Action runners don’t push refresh events to your cache layer, so a cached response will sit there while the bearer token expires. You’ll serve stale queue configs until TTL hits zero.

import redis, json
r = redis.Redis(host='cache.local', port=6379)
# interaction:read tokens roll at 35m, drop cache at 32m
r.setex(f"gc:interaction:config:{queue_id}", 1920, json.dumps(payload))

Are you invalidating on the token refresh event or just relying on fixed TTLs? If the token rolls over, your cache can’t just sit there. Pretty common gotcha when wiring up external HTTPS nodes. The /api/v2/interaction/configurations endpoint returns a 200 even when the token is borderline expired, which masks the issue until the next call. Check the X-RateLimit-Remaining header before you write to Redis. It usually catches people off guard.

4 
{
 "id": "outbound-https-node",
 "settings": {
 "uri": "/api/v2/interaction/configurations",
 "authenticationType": "oauth"
 }
}

Switched authenticationType to oauth. It’s fixed. The header stops stripping. The suggestion above nailed the dropdown fix. The cache warning is real, so don’t store the bearer token in memory. Added a TTL override to the response node. Flow deploys clean now via the module.