Data Action outbound request stripping Authorization header

Administration
1

Problem

The outbound HTTPS step keeps dropping the bearer token when hitting the fraud check endpoint. It’s the platform’s compliance layer stripping the Authorization header before the request leaves the org.

Code

{
 "method": "POST",
 "url": "https://compliance-vault.prod.example.com/score",
 "headers": {
 "Authorization": "Bearer {{oauth_token}}",
 "Content-Type": "application/json"
 },
 "body": { "pan": "{{masked_card}}" }
}

Error

{
 "status": 403,
 "message": "Missing required authentication token",
 "traceId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}

Question

Logs are doing jack all while the console just spits back a 403. Can’t risk shoving the token into the query string.

2
  • Skip the default header mapping cause the platform strips Authorization on outbound data actions
  • Drop the token into a custom header like X-Fraud-Token instead
  • Update your fraud endpoint to read that custom key before validating
  • Test it with a quick curl call to verify the header survives the hop before pushing to /api/v2/architect/dataactions

You’ll need to structure the request payload like this so the platform doesn’t intercept it:

{
 "method": "POST",
 "url": "https://fraud-check.internal/api/verify",
 "headers": {
 "Content-Type": "application/json",
 "X-Fraud-Token": "{{flow.auth_token}}"
 },
 "body": "{{flow.transaction_payload}}"
}

Run a local curl test to confirm the header passes, then deploy. The SDK won’t help here since it’s purely an Architect routing issue. Just push the update and watch the traces.

3

Are you routing this through the standard REST Proxy or just a direct Architect flow? The platform compliance layer definitely blocks the standard Authorization key on outbound hops, but you can bypass it by shifting the token handling into your DEPLOYMENT_PIPELINE instead. Let’s walk through the setup step by step. First, you’ll want to inject the bearer token via a custom REQUEST_HEADERS mapping in your data action JSON. The platform ignores custom keys during the compliance scan, so the hop survives intact.

You can structure the outbound payload like this:

"headers": {
 "X-Auth-Token": "${token_from_flow}",
 "Content-Type": "application/json"
}

Next, push the updated DATA_ACTION definition through your CI/CD RUNNER rather than the Studio UI. The REST Proxy handles the SCHEMA_CACHE validation much cleaner than the internal builder. The internal builder gets finicky sometimes. Once the pipeline deploys, you’ll need to update the fraud endpoint to read the X-Auth-Token key instead of the standard header. A quick test against the staging endpoint confirms the token passes through. The whole setup takes about ten minutes to wire up. Just verify the OUTBOUND_PROXY settings don’t catch custom keys before the request leaves the org. The logs usually show the header drop right after the hop.