Trying to wire up a custom Data Action to hit our internal Lambda via the arn:aws:lambda:us-east-1:123456789012:function:ProcessCallback endpoint. The Data Action JSON looks clean enough, but the invoke keeps bombing out with a 403 from AWS. I’ve got the IAM execution role attached to the Architect tenant, and the policy explicitly allows lambda:InvokeFunction on that ARN. Still getting the usual 403 blast. Weird.
Here’s the Data Action config I’m pushing through the JS SDK:
{
"type": "rest",
"requestMethod": "POST",
"url": "https://lambda.us-east-1.amazonaws.com/2015-03-31/functions/ProcessCallback/invoke",
"headers": {
"Content-Type": "application/json",
"X-Amz-Target": "AWSLambda.Invoke"
},
"body": "{ \"Payload\": \"{\\\"queueId\\\": \\\"{{queue.id}}\\\"}\" }"
}
The IAM trust policy allows genesyscloud.amazonaws.com as a principal, but maybe the runner is actually hitting a different region or using a service-linked role that doesn’t match. I’ve verified the payload structure matches the Lambda input schema. The SDK call to /api/v2/architect/data-actions succeeds, so the schema validation passes. Just the runtime execution fails.
Wondering if there’s a specific IAM condition or signing requirement I’m missing for the X-Amz-Target header. The docs don’t mention SigV4 handling inside the Data Action proxy.