Data Action hitting ServiceNow REST API with a valid OAuth2 token is returning 403 Forbidden. Postman works fine with the same headers, but Genesys drops the Authorization header during execution. Is this a known limitation with the integration runtime?
This sounds like a scope or header propagation issue rather than a platform limitation. When running high-throughput integrations, it is common for the integration runtime to strip or mishandle custom headers if they are not explicitly mapped in the configuration. The 403 suggests the token is either arriving malformed or the ServiceNow endpoint is rejecting the specific OAuth scope attached to the token.
Try moving the Authorization header into the headers object of the HTTP request action instead of passing it as a standard property. The integration runtime sometimes treats standard properties as data payloads rather than HTTP headers. Here is a cleaner way to structure the JSON config for the HTTP action:
{
"url": "https://your-instance.service-now.com/api/now/table/incident",
"method": "POST",
"headers": {
"Authorization": "Bearer ${oauth_token}",
"Content-Type": "application/json"
},
"body": {
"short_description": "Test Incident",
"priority": "2"
}
}
Also, verify the OAuth token lifetime. If the token is generated via a separate flow, it might expire between the generation step and the Data Action execution, especially if there are retries or delays in the flow. A quick check in the integration logs will show the exact request sent out. If the log shows the header is missing, it is definitely a mapping issue. If the header is present but still 403, check the ServiceNow role permissions for the OAuth client. The client might have valid auth but insufficient RBAC permissions to write to the table. This distinction between auth (who you are) and authz (what you can do) often gets missed in initial setups.