Swagger does not allow a stage variable for the account ID

[mparaz]

I am trying to use this Swagger:

paths:
/documents:
post:
responses: {}
security:
- authorizerFunc: []
x-amazon-apigateway-integration:
uri: arn:aws:apigateway:ap-southeast-2:lambda:path/2015-03-31/functions/arn:aws:lambda:ap-southeast-2:${stageVariables.AccountId}:function:${stageVariables.PostFunctionName}/invocations
passthroughBehavior: "when_no_match"
httpMethod: "POST"
type: "aws_proxy"

with the corresponding template:

Resources:

Explicit API Gateway definition needed for the Custom Authorizer.

ApiGatewayApi:
Type: AWS::Serverless::Api
Properties:
DefinitionUri: swaggerFile.yaml
StageName: Prod
Variables:
PostFunctionName: !Ref PostFunction
AccountId: 1234567890

But I get a CloudFormation stack event with:

"ResourceStatusReason": "Errors found during import:\n\tUnable to put integration on 'POST' for resource at path '/documents': Lambda function ARN must be in same account"

It works fine when I put the literal AccountId 1234567890 in the URI.

It looks like the stageVariable reference isn't expanded, is that right?

Thanks!

[sanathkr]

Unfortunately, AccountID has to be hard-coded. This is an APIGateway limitation

[prearrangedchaos]

Region/AccountId would be very usefull. I know this is a limitation on the API Gateway, but could this info not be merged into the swagger file at package time in the CloudFormation cli?

[ffxsam]

@sanathkr could you please explain how this works?

For example:

ApiGatewayApi:
  Type: AWS::Serverless::Api
  Properties:
    DefinitionUri: swaggerFile.yaml
    StageName: Prod
      Variables:
        PostFunctionName: !Ref PostFunction
        AccountId: 1234567890

Why would ${stageVariables.AccountId} not work? It seems we can pass whatever variables we want from the CloudFormation template, correct? Why would PostFunctionName work but not AccountId since it's just another variable?

I'm having a similar issue #178 where I can't pass a Cognito UserPool ARN into a Swagger doc. How are these limitations of API Gateway when I can create an API and set the exact same stage variables & values I'm trying to pass via CloudFormation?

[deddu]

Can we please reopen this issue? Or at least can someone please address the question @ffxsam asked?
Why do some stage variables get interpolated and some do not? Where can we find documentation about this?
EG:

Api:
    Type: AWS::Serverless::Api
    Properties:
      StageName: !Ref Stage
      DefinitionUri: swagger.yml
      Variables:
        #those will be exposed as stage vars in the swagger file, and some, interpolated by api-gw!
        BasePath: !Ref Stage 
        TheLambda: !Ref TheLambda
        TheLambdaARN: !GetAtt TheLambda.Arn # does not work
        Region: !Ref "AWS::Region" # does not work
        AccountId: !Ref "AWS::AccountId" # does not work

WHY?

[spockNinja]

I've ben messing with this problem too. The reason it doesn't work the way we want is probably easiest explained by trying to do the same thing in the AWS Console.

If you view your API's Resources, and dig down into one of the "Integration Request"s that you're working with, you can see the options that are built from this uri.

The lambda ARN literally lets you put in the text "${stageVariables.XYZ}". This is a special feature of cloudformation, letting you route to different lambda functions based on the stage.

The rest of the fields, however, do not allow such dynamic inputs. This also leads us to consider the difference between the API Resource definition and the Stage definition. SAM abstracts a lot of that out for us with the "AWS::Serverless::Api" type, but under the hood, those two things are separate. The swagger template is NOT rendered during stage generation, but during resource generation.

#8 (comment) is probably the closest thing I have found to being able to use those sort of variables dynamically in the swagger file.

[ilazakis]

This is really bad. It basically means that one needs to keep as many copies of the OpenAPI files as stage / region / account permutations they have plus corresponding branching logic on CI and other ops related systems.

That is an unworkable / unrealistic approach and has to be mitigated as soon as possible (unless I am completely misunderstanding the intent of the lambda uri approach).

To minimise the pain, what we did to get around this limitation is include a preprocessing step on CI that replaces the variables in question (in our case it was the AWS region and account id) depending on the context.

[uclaeagit]

Yeah seems like preprocessing is the way to go here. I'm not even using serverless.com for my API Gateway generation - as I want it decoupled from my lambdas - and I still have the same issue. Painful.

[catapim]

Hi guys. Are there any updates on this? We deploy in different stages in different accounts and I just can't figure out how to pass the account Id to my OAS file for Api Gateway

[amt227]

Hello, @sanathkr any updates about passing the accountId and the region to Swagger file?