AWS Lambda
API Gateway
querystring parameters
route parameters
serverless architecture

How to pass a querystring or route parameter to AWS Lambda from Amazon API Gateway

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

API Gateway sends route and query parameters to Lambda inside the incoming event object. The exact event shape changes by API type and payload version, so robust handlers always parse defensively. Good implementations validate input, return consistent errors, and avoid coupling business logic to one fragile event format.

Route and Query Parameters at the Gateway Layer

A route parameter comes from the path template, for example /users/{id}. Query parameters come after the question mark, for example /users/42?status=active&limit=25.

Before coding Lambda logic, confirm three basics:

  • the route template includes expected path variables
  • the deployed stage is updated after route changes
  • the integration is attached to the correct Lambda version or alias

If any of these are wrong, handlers appear broken even though parsing code is correct.

Parse Parameters Safely in Node.js

In Lambda proxy integration, missing maps can be null. Start with safe defaults and validate everything before use.

javascript
1export const handler = async (event) => {
2  const path = event.pathParameters || {};
3  const query = event.queryStringParameters || {};
4
5  const userId = path.id;
6  const status = query.status || "all";
7  const limitRaw = query.limit || "10";
8
9  if (!userId) {
10    return response(400, { error: "missing required path parameter: id" });
11  }
12
13  const limit = Number(limitRaw);
14  if (!Number.isInteger(limit) || limit < 1 || limit > 100) {
15    return response(400, { error: "limit must be an integer between 1 and 100" });
16  }
17
18  return response(200, { userId, status, limit });
19};
20
21function response(statusCode, body) {
22  return {
23    statusCode,
24    headers: { "content-type": "application/json" },
25    body: JSON.stringify(body),
26  };
27}

This pattern keeps validation and response formatting explicit.

Python Handler Equivalent

If your team uses Python, keep behavior aligned so clients receive identical semantics across runtimes.

python
1import json
2
3def handler(event, context):
4    path_params = event.get("pathParameters") or {}
5    query_params = event.get("queryStringParameters") or {}
6
7    user_id = path_params.get("id")
8    if not user_id:
9        return make_response(400, {"error": "missing required path parameter: id"})
10
11    status = query_params.get("status", "all")
12    limit_raw = query_params.get("limit", "10")
13
14    try:
15        limit = int(limit_raw)
16    except ValueError:
17        return make_response(400, {"error": "limit must be an integer between 1 and 100"})
18
19    if limit < 1 or limit > 100:
20        return make_response(400, {"error": "limit must be an integer between 1 and 100"})
21
22    return make_response(200, {"userId": user_id, "status": status, "limit": limit})
23
24
25def make_response(status_code, body):
26    return {
27        "statusCode": status_code,
28        "headers": {"content-type": "application/json"},
29        "body": json.dumps(body),
30    }

Event Shape Differences You Should Expect

HTTP API payload version 2.0 and REST API proxy payload 1.0 are similar but not identical. Some integrations include rawQueryString, while others provide parsed maps directly. Treat event parsing as an adapter layer and isolate it from business logic.

A reliable pattern:

  1. normalize event into an internal request object
  2. validate normalized fields
  3. pass typed values to business functions

This makes migrations between API Gateway modes much safer.

Test End to End with Real Requests

Use simple curl checks for success and failure paths:

bash
curl "https://api.example.com/users/42?status=active&limit=20"
curl "https://api.example.com/users/42?limit=abc"
curl "https://api.example.com/users/"

Then verify CloudWatch logs for parsed values, validation errors, and correlation ids. Include request id in logs so production debugging is fast.

Common Pitfalls

  • Assuming all API Gateway event payloads use the same field names.
  • Reading pathParameters or queryStringParameters without null guards.
  • Skipping numeric and enum validation for query values.
  • Returning inconsistent error schemas across handlers.
  • Forgetting to redeploy stage changes after route updates.
  • Overusing mapping templates when direct proxy events are sufficient.

Summary

  • Route and query values are passed to Lambda through event payload maps.
  • Parse defensively because payload shape varies by API mode.
  • Validate required and typed parameters before business logic.
  • Keep one consistent response format for both success and errors.
  • Normalize event data first to reduce integration coupling.
  • Test real endpoint calls and confirm logs in CloudWatch.

Course illustration
Course illustration

All Rights Reserved.