# 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"}
```

## Deployments and stages

LocalStack follows the AWS deployment model for REST and HTTP APIs: create a [deployment](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-deployments.html) to make your API reachable.
You can create several stages, such as `dev` and `production`, that point to different deployments of your API, each with its own settings and [stage variables](https://docs.aws.amazon.com/apigateway/latest/developerguide/stage-variables.html).
For HTTP APIs, LocalStack also supports [automatic deployments](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-stages.html) of your stages.

:::note
LocalStack 2026.10.0 removed the legacy API Gateway implementation.
Setting `PROVIDER_OVERRIDE_APIGATEWAY`, `PROVIDER_OVERRIDE_APIGATEWAYV2` or `PROVIDER_OVERRIDE_APIGATEWAYMANAGEMENTAPI` to `legacy` or `next_gen` has no effect anymore and logs a warning.
Remove these variables from your configuration.
:::

## 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
custom:
  localstack:
    stages: [local]
functions:
  actionHandler:
    handler: handler.handler
    events:
      - websocket:
          route: test-action
```

Upon deployment of the Serverless project (for example with `sls deploy --stage local`), 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://129ca37e.execute-api.localhost.localstack.cloud:4566",
        "ApiId": "129ca37e",
        ...
    }]
}
```

As on AWS, you connect to a WebSocket API at `<ApiEndpoint>/<stageName>`.
In the above example, the WebSocket URL of the `local` stage is `ws://129ca37e.execute-api.localhost.localstack.cloud:4566/local`.
You can also use the [alternative URL format](#alternative-url-format) on the gateway port: `ws://localhost.localstack.cloud:4566/_aws/execute-api/129ca37e/local`.

Assuming your Serverless project contains a simple Lambda `handler.js` like this:

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

When you send a message to the WebSocket at `ws://129ca37e.execute-api.localhost.localstack.cloud:4566/local`, LocalStack returns the same message as a response on the same WebSocket.

:::note
Before LocalStack 2026.10.0, each WebSocket API was served on its own port from the [external service port range](/aws/customization/networking/external-port-range), and `ApiEndpoint` returned that port, for example `ws://localhost.localstack.cloud:4510`.
To keep this behavior while you migrate, set `APIGW_WEBSOCKETS_LEGACY_PORT=1`: each WebSocket API is then also served on its own port, and that port URL is returned as `ApiEndpoint`.
Connecting through that port without a stage in the path uses the first stage of the API.
This option is deprecated and will be removed in a future release.
:::

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), [HTTP APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-custom-domain-names.html), and [WebSocket APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/websocket-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/
```

For WebSocket APIs, create an API mapping with the API Gateway V2 API, then open the WebSocket connection on the custom domain at the mapping path.
As on AWS, you cannot map WebSocket APIs and REST or HTTP APIs to the same domain name.

## 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

## Limitations

LocalStack accepts the following API Gateway settings through the API, but does not apply them when your API is invoked, or applies them only partially.

### Authorization and access control

- **Resource policies**: LocalStack stores resource policies but does not evaluate them.
- **Private APIs**: `PRIVATE` APIs are reachable without a VPC endpoint.
- **Lambda authorizers**: LocalStack does not cache authorizer results, so `authorizerResultTtlInSeconds` has no effect.
- **Usage plans**: For REST and WebSocket APIs, LocalStack validates API keys against usage plans, but does not enforce throttling or quota limits.
- **`disableExecuteApiEndpoint`**: The default `execute-api` endpoint stays reachable when you disable it.

### Stages and invocation

- Stage and method throttling, caching, access logging, execution logging and X-Ray tracing have no effect.
- LocalStack does not apply the integration timeout (`timeoutInMillis`) or response compression (`minimumCompressionSize`).
- Response streaming (`responseTransferMode: STREAM`) is not supported.
- Client certificates are not sent to HTTP backends.

### Custom domain names

- LocalStack serves custom domains with a TLS certificate it provides or generates. Certificates you provide, and mutual TLS settings, are not used.
- Private custom domain names are not supported. LocalStack treats `PRIVATE` domain names like `REGIONAL` ones.
- `EDGE` domain names do not create a CloudFront distribution.
- You cannot change the endpoint type of an existing REST API domain name.

### Integrations

- For REST APIs, `VPC_LINK` integrations call the integration URI directly.
- The HTTP API AWS service integration subtypes `EventBridge-PutEvents` and `AppConfig-GetConfiguration` are not supported.

## API Coverage (V1)


### API Gateway API coverage

Source service: `apigateway`. 113 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 | 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 | Implemented |
| UpdateUsagePlan | Implemented |
| UpdateVpcLink | Implemented |

## API Coverage (V2)


### API Gateway v2 API coverage

Source service: `apigatewayv2`. 73 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 | 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 | Implemented |
| DeleteStage | Implemented |
| DeleteVpcLink | Implemented |
| ExportApi | 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 | Implemented |
| ListRoutingRules | 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 | 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 |