What this prompt does
This prompt makes the AI configure AWS API Gateway for a [api_purpose] API with [endpoint_count] Lambda-backed endpoints. It compares REST versus HTTP API against your [api_requirements], designs the resource tree for [resources], configures [integration_type] integration with request/response mapping for [mapping_needs], sets up [auth_method] with [auth_scopes], configures throttling at [rate_limit] with usage plans and API keys for [consumer_tiers], adds request validators, configures CORS for [frontend_origins], and sets up [api_domain] with base-path mappings for versioning.
The structure works because it front-loads the decisions that are expensive to change later — REST versus HTTP API, and how usage plans are structured — before consumers are live. Request validation at the gateway rejects malformed requests before they ever reach Lambda, saving invocations. Tiered usage plans for [consumer_tiers] are far easier to design up front than to retrofit onto an API people already depend on. Designing the resource tree for [resources] with proper methods and path parameters from the start also means the URL structure stays stable, which is exactly the kind of thing consumers hate seeing change after they integrate.
When to use it
- You are wiring a public API in front of Lambda where throttling and validation actually matter.
- You need to decide REST API versus HTTP API based on real
[api_requirements]like WebSocket support or usage plans. - You want tiered usage plans and API keys for
[consumer_tiers]designed before consumers go live. - You need request validation at the gateway so invalid requests never reach Lambda.
- You want consistent error reshaping and auth-context injection via mapping for
[mapping_needs]. - You need CORS configured correctly for
[frontend_origins]including preflight handling.
Example output
Expect a configuration spec: a REST-vs-HTTP-API recommendation with the cost/feature trade-off, a resource tree for [resources] with methods and path parameters, [integration_type] integration details with mapping templates for [mapping_needs], an authorizer setup for [auth_method] and [auth_scopes], throttle and usage-plan definitions at [rate_limit] for [consumer_tiers], request-validator config, a CORS policy for [frontend_origins], and a custom-domain setup for [api_domain] with versioning base paths.
Pro tips
- Decide REST versus HTTP API against real
[api_requirements]first; HTTP API is cheaper and faster, but if you need usage plans or WebSocket, that constrains the choice. - Design
[consumer_tiers]usage plans before launch — retrofitting per-key quotas onto a live API with existing consumers is genuinely painful. - Add request validators for body, query, and headers so malformed requests are rejected at the gateway and never burn a Lambda invocation.
- Use mapping templates for
[mapping_needs]to inject auth context and reshape errors into one consistent envelope rather than per-Lambda glue. - Configure CORS for the exact
[frontend_origins]and handle preflight explicitly; wildcard origins on an authenticated API are a security smell. - Set base-path mappings on
[api_domain]for versioning from the start so you can run /v1 and /v2 side by side without a new domain. - Apply throttling at both account and stage level using
[rate_limit]; a stage-level limit protects one environment, but the account-level limit is your last line of defense against a runaway consumer.
