# API Gateway

Source: /aws/services/apigateway/

## Introduction

API Gateway is a managed service that enables developers to create, deploy, and manage APIs (Application Programming Interfaces).
It allows easy creation of REST, HTTP, and WebSocket APIs to securely access data, business logic, or functionality from backend services like AWS Lambda functions or EC2 instances.
API Gateway supports standard HTTP methods such as `GET`, `POST`, `PUT`, `PATCH`, and `DELETE` and integrates with various AWS services, including Lambda, Cognito, CloudWatch, and X-Ray.

LocalStack supports API Gateway V2 (HTTP, Management and WebSocket API) in the Base plan.
LocalStack allows you to use the API Gateway APIs to create, deploy, and manage APIs on your local machine to invoke those exposed API endpoints.

The supported APIs are available on the API coverage section for [API Gateway V1](#api-coverage-v1), [API Gateway V2](#api-coverage-v2), and [API Gateway Management](#api-coverage-api-gateway-management), which provides information on the extent of API Gateway's integration with LocalStack.

## Getting started

This guide is designed for users new to API Gateway and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/cloud-and-iac-commands/#aws) command.

Start your LocalStack container using your preferred method.
We will use the Lambda proxy integration to integrate an API method with a Lambda function.
The Lambda function will be invoked with a `GET` request and return a response with a status code of `200` and a body containing the string `Hello from Lambda!`.

### Create a Lambda function

Create a new file named `lambda.js` with the following contents:

```javascript showshowLineNumbers
'use strict'

const apiHandler = (payload, context, callback) => {
    callback(null, {
        statusCode: 200,
        body: JSON.stringify({
            message: 'Hello from Lambda'
        }),
    }); 
}
    
module.exports = {
    apiHandler,
}
```

The above code defines a function named `apiHandler` that returns a response with a status code of `200` and a body containing the string `Hello from Lambda`.
Zip the file and upload it to LocalStack using the `lstk aws` command.
Run the following command:

```bash showshowLineNumbers
zip function.zip lambda.js
lstk aws lambda create-function \
  --function-name apigw-lambda \
  --runtime nodejs16.x \
  --handler lambda.apiHandler \
  --memory-size 128 \
  --zip-file fileb://function.zip \
  --role arn:aws:iam::111111111111:role/apigw
```

This creates a new Lambda function named `apigw-lambda` with the code you specified.

### Create a REST API

We will use the API Gateway's [`CreateRestApi`](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateRestApi.html) API to create a new REST API.
Here's an example command:

```bash
lstk aws apigateway create-rest-api --name 'API Gateway Lambda integration'
```

This creates a new REST API named `API Gateway Lambda integration`.

```bash title="Output"
{
    "id": "cor3o5oeci",
    "name": "API Gateway Lambda integration",
    "createdDate": "2023-04-27T16:08:46+05:30",
    "apiKeySource": "HEADER",
    "endpointConfiguration": {
        "types": [
            "EDGE"
        ]
    },
    "disableExecuteApiEndpoint": false
}
```

Note the REST API ID returned in the response.
You'll need this ID for the next step.

### Fetch the Resources

Use the REST API ID generated in the previous step to fetch the resources for the API, using the [`GetResources`](https://docs.aws.amazon.com/apigateway/latest/api/API_GetResources.html) API:

```bash
lstk aws apigateway get-resources --rest-api-id <REST_API_ID>
```

```bash title="Output"
{
    "items": [
        {
            "id": "u53af9hm83",
            "path": "/"
        }
    ]
}
```

Note the ID of the root resource returned in the response.
You'll need this ID for the next step.

### Create a resource

Create a new resource for the API using the [`CreateResource`](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateResource.html) API.
Use the ID of the resource returned in the previous step as the parent ID:

```bash showshowLineNumbers
lstk aws apigateway create-resource \
  --rest-api-id <REST_API_ID> \
  --parent-id <PARENT_ID> \
  --path-part "{somethingId}"
```

```bash title="Output"
{
    "id": "zzcvcf56ar",
    "parentId": "u53af9hm83",
    "pathPart": "{somethingId}",
    "path": "/{somethingId}"
}
```

Note the ID of the root resource returned in the response.
You'll need this Resource ID for the next step.

### Add a method and integration

Add a `GET` method to the resource using the [`PutMethod`](https://docs.aws.amazon.com/apigateway/latest/api/API_PutMethod.html) API.
Use the ID of the resource returned in the previous step as the Resource ID:

```bash showshowLineNumbers
lstk aws apigateway put-method \
  --rest-api-id <REST_API_ID> \
  --resource-id <RESOURCE_ID> \
  --http-method GET \
  --request-parameters "method.request.path.somethingId=true" \
  --authorization-type "NONE"
```

```bash title="Output"
{
    "httpMethod": "GET",
    "authorizationType": "NONE",
    "apiKeyRequired": false,
    "requestParameters": {
        "method.request.path.somethingId": true
    }
}
```

Now, create a new integration for the method using the [`PutIntegration`](https://docs.aws.amazon.com/apigateway/latest/api/API_PutIntegration.html) API.

```bash showshowLineNumbers
lstk aws apigateway put-integration \
  --rest-api-id <REST_API_ID> \
  --resource-id <RESOURCE_ID> \
  --http-method GET \
  --type AWS_PROXY \
  --integration-http-method POST \
  --uri arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:000000000000:function:apigw-lambda/invocations \
  --passthrough-behavior WHEN_NO_MATCH
```

The above command integrates the `GET` method with the Lambda function created in the first step.
We can now proceed with the deployment before invoking the API.

### Create a deployment

Create a new deployment for the API using the [`CreateDeployment`](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateDeployment.html) API:

```bash
lstk aws apigateway create-deployment \
  --rest-api-id <REST_API_ID> \
  --stage-name dev
```

Your API is now ready to be invoked.
You can use [curl](https://curl.se/) or any HTTP REST client to invoke the API endpoint:

```bash
curl -X GET http://<REST_API_ID>.execute-api.localhost.localstack.cloud:4566/dev/test
```

```bash title="Output"
{"message":"Hello World"}
```

You can also use our [alternative URL format](#alternative-url-format) in case of DNS issues:

```bash
curl -X GET http://localhost:4566/_aws/execute-api/<REST_API_ID>/dev/test
```

```bash title="Output"
{"message":"Hello World"}
```

## New API Gateway implementation

:::note
The new API Gateway implementation for both v1 (REST API) and v2 (HTTP API), introduced in [LocalStack 3.8.0](https://blog.localstack.cloud/localstack-release-v-3-8-0/#new-api-gateway-provider), is now the default in 4.0.
If you were using the `PROVIDER_OVERRIDE_APIGATEWAY=next_gen` flag, please remove it as it is no longer required.

The legacy provider (`PROVIDER_OVERRIDE_APIGATEWAY=legacy`) is temporarily available but deprecated and will be removed in the next major release.
We strongly recommend migrating to the new implementation.
:::

We're entirely reworked how REST and HTTP APIs are invoked, to closely match the behavior on AWS.
This new implementation has improved parity on several key areas:

- for [REST APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html):
  - properly applying the [request and response data mappings](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html) for all integrations
  - better parity for VTL template rendering ([Mapping Templates](https://docs.aws.amazon.com/apigateway/latest/developerguide/models-mappings.html)) for the integrations supporting it (`AWS`, `HTTP` and `MOCK`)
  - properly supporting [Mapping Templates overrides](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-override-request-response-parameters.html)
  - better parity for `AWS_PROXY` integration payloads
  - out of the box support for most of `AWS` integrations
  - support for [Gateway Responses](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html)
    - we currently only support overriding the Status Code and returning the proper exception, and do not apply mapping template (response body) or parameter mappings (response headers)
- for [HTTP APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html):
  - better validation and parity for most API operations related to HTTP APIs
  - better parity and properly applying [request and response Parameter Mappings](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-parameter-mapping.html) for all integrations
  - we've properly implemented the `AWS_PROXY` [Lambda integration](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html) and `REQUEST` [Lambda Authorizer](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-lambda-authorizer.html) payloads to be fully on parity with AWS
  - better [routing](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-routes.html) handling
  - better [CORS](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-cors.html) handling, especially around automatic `OPTIONS` responses
  - support for [automatic deployments](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-stages.html) of your stages
- For both REST and HTTP APIs:
  - support Stage and Deployments, meaning you can now have different stages pointing to different deployments like in AWS
  - better logging on the different steps in the LocalStack logs

Currently, [WebSockets APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api.html) are still using the default implementation.

As we're closely following AWS, for REST and HTTP APIs, you now need to create a deployment in order for your API to be reachable.
Thanks to this improvement, you can now create different stages point to different deployments of your API (for example, `dev` and `production`) with different settings and stage variables, and those will be reflected in LocalStack.

## LocalStack features

LocalStack provides additional features and functionality on top of the official AWS APIs, to help you develop, debug, and test your local API Gateway APIs.

### Accessing HTTP APIs via Local Domain Name

To demonstrate how to access APIs through LocalStack's local domain name, consider the following Serverless configuration that shows two Lambda functions (`serviceV1` and `serviceV2`) that are connected to an API Gateway v1 (`http` event) and an API Gateway v2 endpoint (`httpApi` event), respectively:

```yaml showshowLineNumbers
...
plugins:
  - serverless-localstack
custom:
  localstack:
    stages: [local]
functions:
  serviceV1:
    handler: handler.handler
    events:
      - http:    # for API GW v1 integration
          method: POST
          path: /my/path1
  serviceV2:
    handler: handler.handler
    events:
      - httpApi: # for API GW v2 integration
          method: POST
          path: /my/path2
```

After you deploy the Lambda functions and API Gateway endpoints, you can access them using the LocalStack edge port (`4566` by default).
There are two alternative URL formats to access these endpoints.

#### Recommended URL format

The recommended URL format for accessing APIs is to use the following URL syntax with an `execute-api` hostname:

```shell
http://<apiId>.execute-api.localhost.localstack.cloud:4566/<stageName>/<path>
```

Here's an example of how you would access the HTTP/REST API with an ID of `0v1p6q6`:

```shell
http://0v1p6q6.execute-api.localhost.localstack.cloud:4566/local/my/path2
```

Note that the local stage ID is added in this example.
Adding the stage ID is required for API Gateway V1 APIs, but optional for API Gateway V2 APIs (in case a `$default` stage is created).
For v2 APIs, the following URL should also work:

```shell
http://0v1p6q6.execute-api.localhost.localstack.cloud:4566/my/path1
```

#### Alternative URL format

The alternative URL format is an endpoint with the predefined base path `/_aws/execute-api`:

```shell
http://localhost:4566/_aws/execute-api/<apiId>/<stageName>/<path>
```

For the example above, the URL would be:

```shell
http://localhost:4566/_aws/execute-api/0v1p6q6/local/my/path1
```

This format is sometimes used in case of local DNS issues.

:::note
If you are using LocalStack 4.0, the following `_user_request_` format is deprecated, and you should use the format above.

```shell
http://localhost:4566/restapis/<apiId>/<stageName>/_user_request_/<path>
```
:::

### WebSocket APIs <Badge text="Pro" size="large" />

WebSocket APIs provide real-time communication channels between a client and a server.
To use WebSockets in LocalStack, you can define a WebSocket route in your Serverless configuration:

```yaml showshowLineNumbers
...
plugins:
  - serverless-localstack
functions:
  actionHandler:
    handler: handler.handler
    events:
      - websocket:
          route: test-action
```

Upon deployment of the Serverless project, LocalStack creates a new API Gateway V2 endpoint.
To retrieve the list of APIs and verify the WebSocket endpoint, you can use the `lstk aws` CLI:

```bash
lstk aws apigatewayv2 get-apis
```

```bash title="Output"
{
    "Items": [{
        "ApiEndpoint": "ws://localhost:4510",
        "ApiId": "129ca37e",
        ...
    }]
}
```

In the above example, the WebSocket endpoint is `ws://localhost:4510`.
Assuming your Serverless project contains a simple Lambda `handler.js` like this:

```javascript
module.exports.handler = function(event, context, callback) {
  callback(null, event);
};
```

You can send a message to the WebSocket at `ws://localhost:4510` and the same message will be returned as a response on the same WebSocket.

To push data from a backend service to the WebSocket connection, you can use the [Amazon API Gateway Management API](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/apigatewaymanagementapi/index.html).
In LocalStack, use the following CLI command (replace `<connectionId>` with your WebSocket connection ID):

```bash
lstk aws apigatewaymanagementapi \
  post-to-connection \
  --connection-id '<connectionId>' \
  --data '{"msg": "Hi"}'
```

## Custom IDs for API Gateway resources via tags

You can assign custom IDs to API Gateway REST and HTTP APIs using the `_custom_id_` tag during resource creation.
This can be useful to ensure a static endpoint URL for your API, simplifying testing and integration with other services.

To assign a custom ID to an API Gateway REST API, use the `create-rest-api` command with the `tags={"_custom_id_":"myid123"}` parameter.
The following example assigns the custom ID `"myid123"` to the API:

```bash
lstk aws apigateway create-rest-api --name my-api --tags '{"_custom_id_":"myid123"}'
```

```bash title="Output"
{
    "id": "myid123",
    ....
}
```

You can also configure the protocol type, the possible values being `HTTP` and `WEBSOCKET`:

```bash showshowLineNumbers
lstk aws apigatewayv2 create-api \
  --name=my-api \
  --protocol-type=HTTP --tags="_custom_id_=my-api"
{
    "ApiEndpoint": "my-api.execute-api.localhost.localstack.cloud:4566",
    "ApiId": "my-api",
    "Name": "my-api",
    "ProtocolType": "HTTP",
    "Tags": {
        "_custom_id_": "my-api"
    }
}
```

:::note
Setting the API Gateway ID via `_custom_id_` works only on the creation of the resource, but not on update in LocalStack.
Ensure that you set the `_custom_id_` tag on creation of the resource.
:::

## Custom Domain Names with API Gateway <Badge text="Pro" size="large" />

You can use custom domain names with API Gateway [REST APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html) and [HTTP APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-custom-domain-names.html).

To use custom domains, you will need to set up an API Gateway Domain Name and create an API Mapping linked to your API.

Assuming your custom domain is set up as `test.example.com` to point to your REST API with a base path mapping `base-path` linked to your stage named `dev`, the following command will be directed to your REST API on the `dev` stage.

You should include the `Host` header with the custom domain name in your request, so you don't need to set up any custom DNS to resolve to LocalStack.

```bash
curl -H 'Host: test.example.com' http://localhost:4566/base-path
```

The request above will be equivalent to the following request:

```bash
curl http://<your-api-id>.execute-api.localhost.localstack.cloud:4566/dev/
```

## API Gateway Resource Browser

The LocalStack Web Application provides a Resource Browser for managing API Gateway resources.
You can access the Resource Browser by opening the LocalStack Web Application in your browser and navigating to the **Resources** section, then clicking on **API Gateway** under the **App Integration** section.

The Resource Browser displays [API Gateway V1](https://app.localstack.cloud/resources/gateway/v1) and [API Gateway V2](https://app.localstack.cloud/resources/gateway/v2) resources.
You can click on individual resources to view their details.

![API Gateway Resource Browser](/images/aws/api-gateway-resource-browser.png)

The Resource Browser allows you to perform the following actions:

- **Create API**: Create a new API ([`V1`](https://app.localstack.cloud/resources/gateway/v1/new)/[`V2`](https://app.localstack.cloud/resources/gateway/v2/new)) by clicking on **Create API** button on top-right and creating a new configuration by clicking on **Submit** button.
- **Edit API**: Edit the API configuration (`V1`/`V2`) by clicking on **Edit API** button on top-right and saving the new configuration by clicking on **Submit** button.
- **Check the Resources**: Click on **Resources** tab to view the resources associated with the API, along with their details, such as `Id`, `ParentId`, `Path Part`, and `Path` and their `HTTP` method.
- **Navigate the Stages**: Click on **Stages** tab to view the stages associated with the API, along with their details, such as `Deployment Id`, `Stage Name`, `Client Certificate Id`, and more.
- **Delete API**: Delete the API configuration (`V1`/`V2`) by selecting the resource, clicking on **Remove Selected** button on top-right and confirming the deletion by clicking on **Continue** button.

You can also use the Resource Browser to check out the **Authorizers**, **Models**, **Request Validators**, **API Keys**, and **Usage Plans**.

## Examples

The following code snippets and sample applications provide practical examples of how to use API Gateway in LocalStack for various use cases:

- [API Gateway with Custom Domains](https://github.com/localstack/localstack-pro-samples/tree/master/apigw-custom-domain)
- [Websockets via API Gateway V2](https://github.com/localstack/localstack-pro-samples/tree/master/serverless-websockets)
- [Serverless Container-based APIs with Amazon ECS and Amazon API Gateway](https://github.com/localstack/serverless-api-ecs-apigateway-sample)
- [Step-up Authentication using Amazon Cognito, DynamoDB, API Gateway Lambda Authorizer, and Lambda functions](https://github.com/localstack/step-up-auth-sample)
- [Serverless Microservices with Amazon API Gateway, DynamoDB, SQS, and Lambda](https://github.com/localstack/microservices-apigateway-lambda-dynamodb-sqs-sample)
- [Note-Taking application using AWS SDK for JavaScript, Amazon DynamoDB, Lambda, Cognito, API Gateway, and S3](https://github.com/localstack/aws-sdk-js-notes-app)
- For Terraform samples, check out the [LocalStack Terraform examples](https://github.com/localstack/localstack-terraform-samples) repository

## API Coverage (V1)


### API Gateway API coverage

Source service: `apigateway`. 111 of 124 tracked operations are implemented.

Service documentation: /aws/services/apigateway/
License availability: service entries on this page start with the Hobby or Base plans; availability can differ by service variant. See /aws/licensing/ for current plan details.

| Operation | Status |
| --- | --- |
| CreateApiKey | Implemented |
| CreateAuthorizer | Implemented |
| CreateBasePathMapping | Implemented |
| CreateDeployment | Implemented |
| CreateDocumentationPart | Implemented |
| CreateDocumentationVersion | Implemented |
| CreateDomainName | Implemented |
| CreateDomainNameAccessAssociation | Not implemented |
| CreateModel | Implemented |
| CreateRequestValidator | Implemented |
| CreateResource | Implemented |
| CreateRestApi | Implemented |
| CreateStage | Implemented |
| CreateUsagePlan | Implemented |
| CreateUsagePlanKey | Implemented |
| CreateVpcLink | Implemented |
| DeleteApiKey | Implemented |
| DeleteAuthorizer | Implemented |
| DeleteBasePathMapping | Implemented |
| DeleteClientCertificate | Implemented |
| DeleteDeployment | Implemented |
| DeleteDocumentationPart | Implemented |
| DeleteDocumentationVersion | Implemented |
| DeleteDomainName | Implemented |
| DeleteDomainNameAccessAssociation | Not implemented |
| DeleteGatewayResponse | Implemented |
| DeleteIntegration | Implemented |
| DeleteIntegrationResponse | Implemented |
| DeleteMethod | Implemented |
| DeleteMethodResponse | Implemented |
| DeleteModel | Implemented |
| DeleteRequestValidator | Implemented |
| DeleteResource | Implemented |
| DeleteRestApi | Implemented |
| DeleteStage | Implemented |
| DeleteUsagePlan | Implemented |
| DeleteUsagePlanKey | Implemented |
| DeleteVpcLink | Implemented |
| FlushStageAuthorizersCache | Not implemented |
| FlushStageCache | Not implemented |
| GenerateClientCertificate | Implemented |
| GetAccount | Implemented |
| GetApiKey | Implemented |
| GetApiKeys | Implemented |
| GetAuthorizer | Implemented |
| GetAuthorizers | Implemented |
| GetBasePathMapping | Implemented |
| GetBasePathMappings | Implemented |
| GetClientCertificate | Implemented |
| GetClientCertificates | Implemented |
| GetDeployment | Implemented |
| GetDeployments | Implemented |
| GetDocumentationPart | Implemented |
| GetDocumentationParts | Implemented |
| GetDocumentationVersion | Implemented |
| GetDocumentationVersions | Implemented |
| GetDomainName | Implemented |
| GetDomainNameAccessAssociations | Not implemented |
| GetDomainNames | Implemented |
| GetExport | Implemented |
| GetGatewayResponse | Implemented |
| GetGatewayResponses | Implemented |
| GetIntegration | Implemented |
| GetIntegrationResponse | Implemented |
| GetMethod | Implemented |
| GetMethodResponse | Implemented |
| GetModel | Implemented |
| GetModelTemplate | Not implemented |
| GetModels | Implemented |
| GetRequestValidator | Implemented |
| GetRequestValidators | Implemented |
| GetResource | Implemented |
| GetResources | Implemented |
| GetRestApi | Implemented |
| GetRestApis | Implemented |
| GetSdk | Not implemented |
| GetSdkType | Not implemented |
| GetSdkTypes | Not implemented |
| GetStage | Implemented |
| GetStages | Implemented |
| GetTags | Implemented |
| GetUsage | Not implemented |
| GetUsagePlan | Implemented |
| GetUsagePlanKey | Implemented |
| GetUsagePlanKeys | Implemented |
| GetUsagePlans | Implemented |
| GetVpcLink | Implemented |
| GetVpcLinks | Implemented |
| ImportApiKeys | Implemented |
| ImportDocumentationParts | Implemented |
| ImportRestApi | Implemented |
| PutGatewayResponse | Implemented |
| PutIntegration | Implemented |
| PutIntegrationResponse | Implemented |
| PutMethod | Implemented |
| PutMethodResponse | Implemented |
| PutRestApi | Implemented |
| RejectDomainNameAccessAssociation | Not implemented |
| TagResource | Implemented |
| TestInvokeAuthorizer | Not implemented |
| TestInvokeMethod | Implemented |
| UntagResource | Implemented |
| UpdateAccount | Implemented |
| UpdateApiKey | Implemented |
| UpdateAuthorizer | Implemented |
| UpdateBasePathMapping | Implemented |
| UpdateClientCertificate | Implemented |
| UpdateDeployment | Implemented |
| UpdateDocumentationPart | Implemented |
| UpdateDocumentationVersion | Implemented |
| UpdateDomainName | Implemented |
| UpdateGatewayResponse | Implemented |
| UpdateIntegration | Implemented |
| UpdateIntegrationResponse | Implemented |
| UpdateMethod | Implemented |
| UpdateMethodResponse | Implemented |
| UpdateModel | Implemented |
| UpdateRequestValidator | Implemented |
| UpdateResource | Implemented |
| UpdateRestApi | Implemented |
| UpdateStage | Implemented |
| UpdateUsage | Not implemented |
| UpdateUsagePlan | Implemented |
| UpdateVpcLink | Implemented |

## API Coverage (V2)


### API Gateway v2 API coverage

Source service: `apigatewayv2`. 67 of 103 tracked operations are implemented.

Service documentation: /aws/services/apigateway/
License availability: service entries on this page start with the Hobby or Base plans; availability can differ by service variant. See /aws/licensing/ for current plan details.

| Operation | Status |
| --- | --- |
| CreateApi | Implemented |
| CreateApiMapping | Implemented |
| CreateAuthorizer | Implemented |
| CreateDeployment | Implemented |
| CreateDomainName | Implemented |
| CreateIntegration | Implemented |
| CreateIntegrationResponse | Implemented |
| CreateModel | Implemented |
| CreatePortal | Not implemented |
| CreatePortalProduct | Not implemented |
| CreateProductPage | Not implemented |
| CreateProductRestEndpointPage | Not implemented |
| CreateRoute | Implemented |
| CreateRouteResponse | Implemented |
| CreateRoutingRule | Not implemented |
| CreateStage | Implemented |
| CreateVpcLink | Implemented |
| DeleteAccessLogSettings | Not implemented |
| DeleteApi | Implemented |
| DeleteApiMapping | Implemented |
| DeleteAuthorizer | Implemented |
| DeleteCorsConfiguration | Implemented |
| DeleteDeployment | Implemented |
| DeleteDomainName | Implemented |
| DeleteIntegration | Implemented |
| DeleteIntegrationResponse | Implemented |
| DeleteModel | Implemented |
| DeletePortal | Not implemented |
| DeletePortalProduct | Not implemented |
| DeletePortalProductSharingPolicy | Not implemented |
| DeleteProductPage | Not implemented |
| DeleteProductRestEndpointPage | Not implemented |
| DeleteRoute | Implemented |
| DeleteRouteRequestParameter | Implemented |
| DeleteRouteResponse | Implemented |
| DeleteRouteSettings | Not implemented |
| DeleteRoutingRule | Not implemented |
| DeleteStage | Implemented |
| DeleteVpcLink | Implemented |
| ExportApi | Not implemented |
| DisablePortal | Not implemented |
| ResetAuthorizersCache | Not implemented |
| GetApi | Implemented |
| GetApiMapping | Implemented |
| GetApiMappings | Implemented |
| GetApis | Implemented |
| GetAuthorizer | Implemented |
| GetAuthorizers | Implemented |
| GetDeployment | Implemented |
| GetDeployments | Implemented |
| GetDomainName | Implemented |
| GetDomainNames | Implemented |
| GetIntegration | Implemented |
| GetIntegrationResponse | Implemented |
| GetIntegrationResponses | Implemented |
| GetIntegrations | Implemented |
| GetModel | Implemented |
| GetModelTemplate | Not implemented |
| GetModels | Implemented |
| GetPortal | Not implemented |
| GetPortalProduct | Not implemented |
| GetPortalProductSharingPolicy | Not implemented |
| GetProductPage | Not implemented |
| GetProductRestEndpointPage | Not implemented |
| GetRoute | Implemented |
| GetRouteResponse | Implemented |
| GetRouteResponses | Implemented |
| GetRoutes | Implemented |
| GetRoutingRule | Not implemented |
| ListRoutingRules | Not implemented |
| GetStage | Implemented |
| GetStages | Implemented |
| GetTags | Implemented |
| GetVpcLink | Implemented |
| GetVpcLinks | Implemented |
| ImportApi | Implemented |
| ListPortalProducts | Not implemented |
| ListPortals | Not implemented |
| ListProductPages | Not implemented |
| ListProductRestEndpointPages | Not implemented |
| PreviewPortal | Not implemented |
| PublishPortal | Not implemented |
| PutPortalProductSharingPolicy | Not implemented |
| PutRoutingRule | Not implemented |
| ReimportApi | Implemented |
| TagResource | Implemented |
| UntagResource | Implemented |
| UpdateApi | Implemented |
| UpdateApiMapping | Implemented |
| UpdateAuthorizer | Implemented |
| UpdateDeployment | Implemented |
| UpdateDomainName | Implemented |
| UpdateIntegration | Implemented |
| UpdateIntegrationResponse | Implemented |
| UpdateModel | Implemented |
| UpdatePortal | Not implemented |
| UpdatePortalProduct | Not implemented |
| UpdateProductPage | Not implemented |
| UpdateProductRestEndpointPage | Not implemented |
| UpdateRoute | Implemented |
| UpdateRouteResponse | Implemented |
| UpdateStage | Implemented |
| UpdateVpcLink | Implemented |

## API Coverage (API Gateway Management)


### API Gateway Management API API coverage

Source service: `apigatewaymanagementapi`. 3 of 3 tracked operations are implemented.

Service documentation: /aws/services/apigateway/
License availability: service entries on this page start with the Hobby or Base plans; availability can differ by service variant. See /aws/licensing/ for current plan details.

| Operation | Status |
| --- | --- |
| DeleteConnection | Implemented |
| GetConnection | Implemented |
| PostToConnection | Implemented |