Demystifying API Gateway integration types

API gateway integrations connect the gateway to various backend services, such as Lambda functions, HTTP/S endpoints, or other cloud services. The specific integration types and configurations depend on the chosen API gateway provider and the target backend.
In this article I will explain the integration types and when to use each one.

I will divide them by 3 use cases:

1. The "Builder" tools (Lambda & Mock integrations) This one focuses on how to connect to serverless functions or create a fake backend for testing.
2. The "Connector" Tools (HTTP & Private) Here the focus is on how to talk to other public websites or secure services hidden inside a private network (VPC).
3. The "Power User" Tool (AWS Service) Focus on the advanced method of connecting directly to other AWS services (like DynamoDB) without writing any code.

Let's jump into the Builder Tools.
In this integration type we basically integrate with an "AWS Lambda" function, and sometimes we just use a "Mock Integration", when integrating with a lambda function, the code will execute the logic. talks to databases, or processes data. While in Mock Integration the API will just return static, hardcoded responses without actually running any backend code.

1. Lambda Integration
This is the most popular integration. When a user hits your API endpoint (e.g., GET /users), API Gateway triggers a specific AWS Lambda function.
The Crucial Decision is to choose between Proxy or Non-Proxy, this is the single most important setting to understand here.

Feature	Proxy Integration (The Pipe)	Non-Proxy Integration (The Prep Chef)
How it works	API Gateway passes the entire raw request (headers, body, query params) directly to your Lambda function.	API Gateway transforms the request before sending it. It can filter data, rename parameters, or change JSON to XML.
Who does the work?	Your Lambda code must parse the request and format the response perfectly.	API Gateway handles the messy parsing; your Lambda just receives clean data.
Best for...	Modern, standard APIs where you want full control in your code.	Legacy systems or when you need to clean up data before your code sees it.

2. Mock Integration (The Placeholder)
This is exactly what it sounds like. You configure the API to say: "If someone calls this endpoint, just send back this specific JSON."
Why would you use this?
The Mock will return fake data, so the frontend team keeps working while the backend code is still being developed.
You want to test how your app handles a "500 Server Error" without actually breaking your server.

The "Connector" Tools (HTTP & Private)
Now, let's look at how we connect to services that already exist somewhere else (not Lambda functions you just wrote).

3. HTTP Integration (The Messenger)
Think of this as a "pass-through." You already have a web application running somewhere else (like a legacy server or a third-party API like Google Maps). You want API Gateway to sit in front of it.
The API Gateway receives the request and forwards it straight to another URL.
Use this if you are migrating an old API to AWS. You can put API Gateway in front of your old server. To the user, it looks like a modern AWS API, but behind the scenes, it's still talking to the old server until you're ready to upgrade it.

4. Private Integration (The Secure Tunnel)
This is for when your backend is hidden and not accessible via the public internet.
You may have a database or service running on an EC2 instance inside an Amazon VPC. It is secure with no public IP address.
Since it's private, API Gateway can't normally reach it.
Private Integration uses a component called VPC Link to create a secure tunnel into your private network to talk to that hidden service.

The "Power User" Tool (AWS Service)
This is the final and often most misunderstood integration type.
Most people think: "If I want to save data to a database, I need a Lambda function to do it." AWS Service Integration says: "No, you don't."

5. AWS Service Integration (The Shortcut)
This allows API Gateway to talk directly to other AWS services like DynamoDB, SQS, SNS, or Kinesis; there is no need for a Lambda function.

• How it works: API Gateway acts as the "client." When a request comes in, API Gateway translates it into the specific format that the AWS service (like DynamoDB) expects and sends it.
• The "Cost": You have to set up Mapping Templates (using a language called VTL). You have to explicitly tell API Gateway: "Take the 'user_id' from the URL and put it into a DynamoDB PutItem command."

Why not just use Lambda?

1. You don't pay for Lambda execution time.
2. One less hop means lower latency.

A common use case is the "Contact Us" form, imagine a high-traffic "Contact Us" form on a website.

• The Old Way: API GW - Lambda - SQS Queue.
• The Better Way: API GW - SQS Queue.

Summary of the five integration types:

Integration Type	Best Use Case
Lambda	Running custom business logic or calculations.
HTTP	Proxying to existing web apps or 3rd party APIs.
Mock	Testing, unblocking front-end teams, or handling errors.
Private	Accessing internal/private resources inside a VPC.
AWS Service	High-performance, direct actions without code.

You have learned about all the API Gateway integration types, are you interested in specific further details to learn about API Gateway? Let me know in the comments!