Free tools Windows power users keep installed
One-click scans. No signup required.
Use an OpenAPI definition to describe your API’s routes and add API Gateway’s x-amazon-apigateway-integration extension to each operation that should invoke Lambda. Import the definition into API Gateway, configure the Lambda invocation permission and deployment stage, then test the deployed routes. The exact integration settings depend on whether you create a REST API or an HTTP API.
Choose REST API or HTTP API before writing the integration
Both API types can use OpenAPI to define routes, but they do not accept the same OpenAPI versions or support identical API Gateway integration features. The AWS documentation pages Develop REST APIs using OpenAPI in API Gateway, OpenAPI extensions for API Gateway, and Use OpenAPI definitions for HTTP APIs in API Gateway describe these differences.
| Decision point | REST API | HTTP API |
|---|---|---|
| OpenAPI import | OpenAPI 2.0 or 3.0 | OpenAPI 3.0 |
| Integration model | Broader set of API Gateway extensions and integration options | Narrower integration model; the cited AWS guide covers Lambda proxy and HTTP proxy integrations |
| Moving an existing REST API | Can be exported as OpenAPI 3.0 | Can be created by importing an OpenAPI 3.0 definition exported from a REST API, subject to HTTP API support for the definition’s features |
| Exporting the API definition | Can export as OpenAPI 2.0 or 3.0 in JSON or YAML, with optional API Gateway extensions | The cited export workflow applies to REST APIs |
Choose based on the authorizers, request or response mapping and transformation, protocol features, and cost and performance goals your workload requires. Confirm that the specific features in your definition are supported by the selected API type; an HTTP API import can issue warnings for unsupported combinations.
How the OpenAPI-to-Lambda connection works
OpenAPI describes the public API contract: paths, operations, parameters, request and response formats, and schemas. API Gateway’s vendor extensions add AWS-specific configuration to that contract. The key extension for connecting an operation to a backend is x-amazon-apigateway-integration.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
For a Lambda-backed operation, that integration must target the Lambda function’s ARN and specify the integration behavior appropriate to the chosen API type and proxy mode. There is no single URI or payload configuration that is correct for every REST API and HTTP API combination. Use the integration format documented for your API type rather than copying a URI from a different API configuration.
Other API Gateway extensions can express gateway-specific behavior, including authorization, CORS, and request validation. The API Gateway extensions guide explains which extensions apply to REST APIs, HTTP APIs, or both. An OpenAPI definition without the necessary integration settings describes routes, but does not by itself establish how those routes invoke Lambda.
Prepare the definition and Lambda function
Before importing, decide which API type and Lambda invocation pattern you intend to use. Then prepare an OpenAPI 2.0 or 3.0 document for a REST API, or OpenAPI 3.0 for an HTTP API. Include the usual API information, paths, operations, and schemas, along with the API Gateway extensions required for the chosen design.
- Add an integration extension to each operation that should invoke Lambda; identify the target function ARN and use the correct integration settings for the API type and proxy mode.
- Keep the API Gateway and Lambda function in the same AWS Region, as required by the implementation guidance.
- Ensure API Gateway has permission to invoke the function. A valid OpenAPI definition does not replace this permission.
- For an HTTP API, check that the authorization and integration patterns in the document are supported before importing.
The official documentation establishes the import and export capabilities, but it does not verify a deployment in a particular AWS account, Region, runtime, or infrastructure tool. Check current AWS guidance for invocation permissions, authorizers, quotas, and other configuration details specific to your environment.
Import the OpenAPI definition
For a REST API, use API Gateway’s OpenAPI import operation to create an API or update one that already exists. When updating, choose the import behavior deliberately:
- Overwrite: use when the definition should replace the existing API configuration represented by the import.
- Merge: use when you intend to combine the imported definition with the existing API configuration.
Review the import result for warnings or errors, especially when the definition uses extensions or features whose support differs by API type. For an HTTP API, import an OpenAPI 3.0 definition and resolve any warnings that indicate unsupported configuration rather than assuming the imported API behaves exactly like a REST API.
Rank #4
Deploy and verify the routes
Importing defines or updates the API configuration; you must also configure deployment and stage settings before invoking the deployed routes. After deployment, test representative operations and inspect API Gateway and Lambda logs to check that requests reach the expected function and that the request and response behavior matches the API contract.
- Configure the deployment and stage settings for the API.
- Invoke representative routes using requests that exercise the expected parameters and payloads.
- Review API Gateway and Lambda logs to diagnose invocation, authorization, mapping, or response issues.
A successful import is not evidence that a particular route can invoke its Lambda function: deployment, permissions, and operation-level integration configuration all matter.
Export a REST API as OpenAPI
When you need a versioned backup or a definition to adapt for another API, export the deployed REST API as OpenAPI 2.0 or 3.0, in JSON or YAML. Include API Gateway integration extensions in the export when you need AWS-specific integration configuration represented in the resulting document. Without those extensions, the exported API contract may not carry the gateway integration details needed for a round trip.
Check model content types before relying on an export/import round trip. The documented REST export flow constrains exported models to JSON payloads, so model content types outside that constraint may not be preserved as expected.
Use a REST export as the starting point for HTTP API migration
A documented migration path is to export a REST API as OpenAPI 3.0 and import that definition as an HTTP API. Treat the export as a starting point, not a guarantee of feature equivalence: HTTP APIs have a narrower integration model, and unsupported combinations can produce import warnings. Review route integrations, authorization, mapping or transformation behavior, and other API Gateway-specific features against HTTP API support before relying on the migrated configuration.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
