Integrating with Lambda
~8 min read
How API Gateway turns a Lambda function into a real HTTP endpoint.
In a Lambda Proxy integration (the most common and recommended pattern), API Gateway passes the entire incoming request (path, query parameters, headers, body) as a structured event object to the Lambda function, and expects the function to return a response in a specific shape: {"statusCode": 200, "headers": {...}, "body": "..."} (with the body typically a JSON string, not a raw object). API Gateway handles translating this back into a proper HTTP response to the client.
A common early-development mistake is a Lambda function returning a plain object or just the intended response body directly, rather than wrapping it in this expected {statusCode, headers, body} structure — this causes a generic 500 error at the API Gateway layer that can be confusing to debug without knowing this specific contract.
Non-proxy (custom) integrations give more control — you can define mapping templates to transform the request before it reaches Lambda and the response before it reaches the client — but require meaningfully more configuration and are used far less often than the simpler, more common proxy integration pattern.
💻 Code example
# Example Lambda Proxy integration response shape (Python)
import json
def handler(event, context):
order_id = event['pathParameters']['id']
return {
'statusCode': 200,
'headers': {'Content-Type': 'application/json'},
'body': json.dumps({'orderId': order_id, 'status': 'shipped'})
}
💬 Deep Dive with AI
Key points
- •Lambda Proxy integration passes the full request as an event and expects a specific {statusCode, headers, body} response shape
- •Returning a plain object instead of this expected shape causes a confusing 500 error
- •Non-proxy integrations allow custom request/response transformation but require much more configuration
- •Proxy integration is the default, recommended choice for the vast majority of Lambda-backed APIs