Architect Data Action 403: Lambda InvokePermission missing despite trust policy

I’ve been wrestling with an Architect Data Action that calls a Lambda function to enrich call data before routing. The flow works locally when I test the Lambda directly, but through the Genesys Cloud Architect, I’m hitting a hard 403 Forbidden.

Here’s the setup. I have a custom agent desktop widget built with the Embeddable Client App SDK that triggers this flow. The Data Action is configured to POST to https://lambda.us-east-1.amazonaws.com/2015-03-31/functions/arn:aws:lambda:us-east-1:123456789012:function:enrichment-func/invoke.

The IAM role attached to the Genesys Cloud integration user has lambda:InvokeFunction permission. I even added a resource-based policy to the Lambda function itself to allow the specific IAM role ARN. The trust policy looks like this:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "AWS": "arn:aws:iam::123456789012:role/GenesysIntegrationRole"
 },
 "Action": "lambda:InvokeFunction",
 "Resource": "arn:aws:lambda:us-east-1:123456789012:function:enrichment-func"
 }
 ]
}

The response from Architect’s debug trace shows the 403 error body:

{
 "message": "User: arn:aws:sts::123456789012:assumed-role/GenesysIntegrationRole/session-name is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-east-1:123456789012:function:enrichment-func"
}

I’ve tried adding the lambda:InvokeAsync permission just in case, but that didn’t change anything. I also checked the CloudWatch logs for the Lambda, and the function isn’t even being invoked, which confirms the rejection is happening at the API gateway level before execution.

Is there a specific header or auth method Genesys uses for these Data Actions that I’m missing? Or is it a known issue with how the STS assumed role is resolved against the Lambda resource policy? I’m running on the us-east-1 cluster, so region alignment isn’t the culprit.

I’ve double-checked the ARN spelling and the role name. Everything seems correct. The weird part is that if I use the AWS CLI with the same credentials, it works fine. It’s only failing when initiated from the Architect flow.

Any ideas on what I’m missing here? I’m stumped. I’ve spent two days on this IAM config. It’s driving me crazy. I just want the data to flow through without the 403.