Architect REST step fails repeatedly with a 422 when the Node service tries to patch interaction context variables through the purecloud-platform-client-v2 client. Platform SDK for JS defaults the content type to application/json but drops the x-gw-ims-org-id header on outbound webhook callbacks, which breaks the IVR routing logic. Direct cURL works fine, but the SDK call fails every single time, and the retry logic doesn’t catch it.
- Node v18.17,
purecloud-platform-client-v2 135.0.0
- Architect flow version 4.2, REST step set to PATCH
/api/v2/analytics/icm/interactions
- Payload includes
routing.queue.id and custom_attributes
- Auth token refreshes correctly, no 401s
{
"code": "notAcceptable",
"message": "Invalid request body. Missing required field: interactionId",
"status": 422
}
The SDK strips custom headers on outbound callbacks unless you explicitly override the HEADER CONFIGURATION in the ADMIN UI first. You’ll need to inject the IMS header directly into the request config before patching the INTERACTION CONTEXT.
const api = require('purecloud-platform-client-v2').platformClient;
api.ApiClient.instance.setHeaders({ 'x-gw-ims-org-id': 'your-ims-org-id' });
You might want to pause before hardcoding the x-gw-ims-org-id directly in the client initialization. That approach bypasses the standard secret rotation policy and leaves the org identifier exposed in the deployment logs. Does the current deployment pipeline log the raw header payload? The platform expects outbound webhook callbacks to inherit the originating flow’s authentication context automatically.
If the SDK is stripping the header, the issue usually sits in the Architect flow configuration rather than the Node service. Check the REST step settings. The “Pass Authentication” toggle needs to remain enabled so the platform injects the x-gw-ims-org-id and the access token at runtime. Disabling it breaks the audit chain and triggers the 422 validation error. Works fine in staging. Usually breaks in prod.
[screenshot of architect flow REST step configuration]
The recent community discussion on webhook authentication covers this exact behavior. Hardcoding headers in the SDK also violates SOC2 control requirements for credential management. How does the current setup handle token expiration during PCI secure flow ? The system will reject requests that don’t match the expected signature rotation. You’ll need to revert the setHeaders override and verify the flow’s outbound security policy. The platform handles token refresh automatically when the flow context is preserved.
Audit logs will flag any manual header injection as an unauthorized configuration change. Better to align with the default authentication flow. The validator will catch it anyway.