API Gateway

AWS LabsOfficialPublished by AWS Labs

Skill
Tool integration
Cloud and DevOps
Apache-2.0
No issues found

From the author

Build, manage, and operate APIs with Amazon API Gateway (REST, HTTP, and WebSocket). Triggers on phrases like: API Gateway, REST API, HTTP API, WebSocket API, custom domain, Lambda authorizer, usage plan, throttling, CORS, VPC link, private API. Also covers troubleshooting API Gateway errors (4xx, 5xx, timeout, CORS failures) and IaC templates containing API Gateway resources. For general REST API design unrelated to AWS, do not trigger.

— the description by AWS Labs

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides comprehensive support for Amazon API Gateway, covering the full lifecycle of API development. It helps users choose between REST, HTTP, and WebSocket APIs based on specific requirements like cost, latency, and management features. The skill includes guidance on architecture patterns, security configurations (including mTLS and Lambda authorizers), performance tuning, and observability. It also provides troubleshooting steps for common errors and supports IaC implementation using SAM, CloudFormation, and CDK.

What it does

Assists in selecting the appropriate API type (REST, HTTP, or WebSocket) based on enterprise needs.
Provides architectural patterns for multi-tenant SaaS, private APIs, and cross-account deployments.
Offers troubleshooting workflows for common 4xx and 5xx errors, including CORS and timeout issues.
Guides the implementation of security controls like Lambda authorizers, JWT, and mTLS.
Generates IaC templates for API Gateway resources using SAM, CloudFormation, or CDK.
Configures performance settings such as throttling, usage plans, and caching strategies.

When to use it

When designing or deploying APIs on AWS using API Gateway.
When you need to troubleshoot API Gateway errors like 403, 502, 504, or CORS failures.
When implementing security, authentication, or authorization for serverless APIs.
When you need to optimize API performance, scaling, or observability.
When you require Infrastructure as Code templates for API Gateway resources.

Advantages

Reduces development time by providing clear decision trees for API types and auth methods.
Minimizes configuration errors by highlighting common pitfalls and service limits.
Ensures consistent deployment practices through standardized IaC patterns.
Simplifies complex tasks like setting up mTLS or cross-account API routing.
Provides a structured approach to observability and logging for production readiness.

Usage examples

“I need to build a REST API that requires per-consumer throttling and request validation. Which API type should I use?”: The agent will recommend the REST API (v1) and explain how to configure usage plans and request validation to meet your requirements.
“My API is returning a 504 timeout error. How can I fix this?”: The agent will guide you through checking backend latency, suggest optimizing the integration, or explain how to request a timeout increase for Regional/Private endpoints.
“Generate a SAM template for a private API Gateway REST API.”: The agent will provide a complete SAM/CloudFormation YAML template configured for a private endpoint, including necessary VPC link resources.
“How do I set up mTLS for my API Gateway?”: The agent will explain the requirements for Regional custom domains, S3 truststore configuration, and the necessary security policies.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/awslabs/api-gateway/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip api-gateway.zip -d .agents/skills

Documentation by AWS Labs

Amazon API Gateway Development

Expert guidance for building, managing, governing, and operating APIs with Amazon API Gateway. Covers REST APIs (v1), HTTP APIs (v2), and WebSocket APIs.

How to Use This Skill

When answering API Gateway questions:

Read the relevant reference file(s) before responding, do not rely solely on this summary
For tasks spanning multiple concerns (e.g., "private API with mTLS and custom domain"), read all relevant references
When the user needs IaC templates, consult references/sam-cloudformation.md or references/sam-service-integrations.md and provide complete, working SAM/CloudFormation YAML
Always mention relevant pitfalls and limits that affect the user's design

Quick Decision: Which API Type?

Choose the right API type first. This decision affects every downstream choice.

REST API is the full-featured API management platform for enterprises. It provides the governance, security, monetization, and operational controls that organizations need to build, publish, and manage APIs at scale, including usage plans with per-consumer throttling and quotas, API keys, request validation, WAF integration, resource policies, caching, canary deployments, and private endpoints.

HTTP API is the lightweight, low-cost proxy optimized for simpler API workloads. It offers ~70% lower cost and lower latency but trades away the API management features. Choose HTTP API when you need a fast, lightweight proxy to Lambda or HTTP backends and don't require the enterprise controls above.

Factor	REST API (v1)	HTTP API (v2)	WebSocket API
Positioning	Full API management	Low-cost proxy	Real-time bidirectional
Cost	Higher	~70% cheaper	Per-message pricing
Latency	Higher	Lower	Persistent connection
Max timeout	50ms-29s (up to 300s Regional/Private)	30s hard limit	29s
Payload	10 MB	10 MB	128 KB message / 32 KB frame
API Management
Usage plans/API keys	Yes	No	No
Request validation	Yes (JSON Schema draft 4)	No	No
Caching	Yes (0.5-237 GB)	No	No
Custom gateway responses	Yes	No	No
VTL mapping templates	Yes	No (parameter mapping only)	Yes
Security & Governance
WAF	Yes	No (use CloudFront + WAF)	No
Resource policies	Yes	No	No
Private endpoints	Yes	No	No
mTLS	Yes (Regional custom domain only)	Yes (Regional custom domain only)	Via CloudFront viewer mTLS
Auth
Lambda authorizer	Yes (TOKEN + REQUEST)	Yes (REQUEST only, simple + IAM policy format)	Yes (REQUEST on $connect only)
JWT authorizer	No (use Cognito authorizer)	Yes (native)	No
Cognito authorizer	Yes (native)	Use JWT authorizer	No
Operations
Canary deployments	Yes	No	No
Response streaming	Yes	No	No
X-Ray tracing	Yes	No	No
Execution logging	Yes	No	Yes
Custom domain sharing	Not with WebSocket	Not with WebSocket	Not with REST/HTTP

Use REST API when: you are building APIs for external consumers, partners, or multi-tenant platforms; need to enforce per-consumer rate limits and quotas; require request validation, caching, or WAF at the API layer; need private endpoints, resource policies, or canary deployments; or are building an API product with monetization and governance requirements.

Use HTTP API when: you are building lightweight APIs or simple backend proxies; cost and latency are the primary concerns; you don't need per-consumer throttling, request validation, caching, or WAF at the API layer; and native JWT authorization with OIDC/OAuth 2.0 meets your auth needs. Accept the hard 30s timeout and lack of API management features. For WAF, edge caching, or edge compute, place a CloudFront distribution in front of the HTTP API.

Use WebSocket API when you need: persistent bidirectional connections for real-time use cases (chat, notifications, live dashboards).

Instructions

Step 1: Design the API

Before implementation, gather requirements systematically. Consult references/requirements-gathering.md for the full requirements workflow covering endpoints, auth, data models, performance, security, and deployment needs.

Key design decisions:

API type: Use the decision table above
Endpoint type: Edge-optimized (default for global clients; optimizes TCP connections via CloudFront POPs but does not cache at the edge), Regional (same-region clients, or global clients needing their own CloudFront distribution for edge caching, edge compute, granular WAF control, or geo-based routing), Private (VPC-only access, REST API only)
Topology: Centralized (single domain, path-based routing) vs Distributed (subdomains per service)
Authentication: See references/authentication.md for the decision tree

Step 2: Implement the API

Consult these references based on what you're building:

Architecture patterns: references/architecture-patterns.md: topology, multi-tenant SaaS, hybrid workloads, private APIs, multi-region, streaming
WebSocket API: references/websocket.md: route selection, @connections management, session management, client resilience, SAM templates, limits, multi-region
Service integrations: references/service-integrations.md: direct AWS service integrations (EventBridge, SQS, SNS, DynamoDB, Kinesis, Step Functions, S3), HTTP proxy, mock, VTL mapping templates, binary media types, Lambda sync/async invocation
Custom domains and routing: references/custom-domains-routing.md: base path mappings, routing rules, header-based versioning
Security: references/security.md: mTLS (API Gateway native + CloudFront viewer mTLS), TLS policies, resource policies, WAF, HttpOnly cookies, CRL checks
SAM/CloudFormation: references/sam-cloudformation.md: IaC patterns, OpenAPI extensions, VTL reference, binary data
SAM service integration templates: references/sam-service-integrations.md: EventBridge, SQS, DynamoDB CRUD, Kinesis, Step Functions (REST + WebSocket) templates

Step 3: Configure Performance and Scaling

Throttling: Account-level default is 10,000 rps / 5,000 burst (adjustable; request increases via AWS Support). Configure stage-level and method-level throttling via usage plans. See references/performance-scaling.md
Caching (REST only): Default TTL 300s, max 3600s. Only GET methods cached by default. Max cached response 1 MB
Edge caching (all API types): For edge caching, place a self-managed CloudFront distribution in front of a Regional API. CloudFront reduces latency, backend load, AND cost (cached responses never reach API Gateway). Also enables edge compute (CloudFront Functions, Lambda@Edge) and granular cache behaviors per path. Use a Regional endpoint, not edge-optimized, when pairing with your own CloudFront distribution
Scaling: API Gateway scales automatically but plan the entire stack (Lambda concurrency, DynamoDB capacity)

Step 4: Set Up Observability

Always configure access logging. For REST and WebSocket APIs, also enable execution logging (ERROR level for production, INFO only for debugging). HTTP API does not support execution logging; use access logs with enhanced observability variables instead.

Consult the observability references based on what you need:

Logging setup, log formats, retention: references/observability-logging.md
Metrics, alarms, metric filters, X-Ray tracing: references/observability-metrics-alarms.md
Log analysis and insights, analytics pipeline, cross-account, control plane logs: references/observability-analytics.md

Step 5: Deploy

Use Infrastructure as Code (SAM, CDK, CloudFormation, Terraform) for production
Canary deployments (REST only): Route a percentage of traffic to test new versions
Blue/green deployments: Use custom domain API mappings to switch between environments with zero downtime
Routing rules (preferred for new domains): Declarative header/path-based routing on custom domains for versioning, A/B testing, gradual rollouts, and cell-based routing
See references/deployment.md for detailed patterns

Step 6: Apply Governance

For organization-wide API standards, see references/governance.md covering:

Preventative controls (SCPs, IAM policies)
Proactive controls (CloudFormation Hooks, Guard rules)
Detective controls (AWS Config rules, EventBridge)
Specific enforcement examples for security, observability, and management

Response Format

When responding to API Gateway questions, structure your answer as:

Recommendation: Lead with the recommended approach and why
Code: Include SAM/CloudFormation YAML or code when the user needs implementation (always read the relevant reference file first)
Pitfalls: Warn about relevant gotchas from the pitfalls below or from references/pitfalls.md
Limits: Mention any service limits that constrain the design

Troubleshooting Quick Reference

When diagnosing API Gateway errors, consult references/troubleshooting.md for detailed resolution steps. Here are the most common issues:

Error	Most Common Cause	Quick Fix
400 Bad Request	Protocol mismatch (HTTP/HTTPS) with ALB	Match protocol to listener type
401 Unauthorized	Wrong token type (ID vs access) or missing identity sources	Check token type matches scope config; verify all identity sources sent
403 Missing Auth Token	Stage name in URL when using custom domain	Remove stage name from URL path
403 from VPC	Private DNS on VPC endpoint intercepts ALL API calls	Use custom domain names for public APIs
403 Access Denied	Resource policy + auth type mismatch or missing redeployment	Review policy, check auth type, redeploy API
403 mTLS	Certificate issuer not in truststore or weak signature algorithm	Verify CA in truststore, use SHA-256+
429 Too Many Requests	Account/stage/method throttle limits exceeded	Implement jittered exponential backoff; request limit increase
500 Internal Error	Missing Lambda invoke permission (especially with stage variables)	Add resource-based policy to Lambda function
502 Bad Gateway	Lambda response not in required proxy format	Return `{statusCode, headers, body}` from Lambda
504 Timeout	Backend exceeds 29s (REST, increasable) or 30s (HTTP, hard). HTTP API body says "Service Unavailable" but status is 504	Optimize backend, request timeout increase (REST Regional/Private), or switch to async invocation
CORS errors	Missing CORS headers on Gateway Responses (4XX/5XX)	Add CORS headers to DEFAULT_4XX and DEFAULT_5XX gateway responses
SSL/PKIX errors	Incomplete certificate chain on backend	Provide full cert chain; use `insecureSkipVerification` only for testing

Critical Pitfalls

REST API default timeout is 29 seconds (increasable up to 300s for Regional/Private endpoints via quota request). Lambda continues running but client gets 504. Request a timeout increase, or consider async patterns (SQS, EventBridge) for better user experience on long operations
HTTP API hard timeout is 30 seconds. Returns {"message":"Service Unavailable"} while Lambda continues
/ping and /sping are reserved paths. Do not use for API resources
Execution log events truncated at 1,024 bytes. Use access logs for complete data
413 REQUEST_TOO_LARGE is the only gateway response that cannot be customized. Use DEFAULT_4XX as a catch-all to add CORS headers for all 4xx errors including 413
maxItems/minItems not validated in REST API request validation
Root-level security in OpenAPI is ignored. Must set per-operation
JWT authorizer public keys cached 2 hours. Account for this in key rotation
Management API rate limit: 10 rps / 40 burst. Heavy automation can hit this
Always redeploy REST API after configuration changes. Changes don't take effect until deployed
Edge-optimized endpoints do NOT cache at the edge — they only optimize TCP connections via CloudFront POPs. If you need edge caching, edge compute (CloudFront Functions, Lambda@Edge), or granular CloudFront control, use a Regional API with your own CloudFront distribution instead

For additional pitfalls (header handling, URL encoding, caching charges, canary deployments, usage plans), see references/pitfalls.md.

IaC Framework Selection

Default: CDK TypeScript

Override syntax:

"use SAM" → Generate SAM/CloudFormation YAML templates
"use CloudFormation" → Generate CloudFormation YAML templates
"use Terraform" → Generate Terraform HCL

When not specified, ALWAYS use CDK TypeScript.

Error Scenarios

MCP Server Unavailable

Inform user: "AWS Serverless MCP not responding"
Ask: "Proceed without MCP support?"
DO NOT continue without user confirmation

Service Limits Quick Reference

See references/service-limits.md for the complete table. Most numeric quotas below are default values and adjustable; check with your AWS account team and the latest quotas page before using them for architectural decisions. Key limits:

Resource	REST API	HTTP API	WebSocket
Payload size	10 MB	10 MB	128 KB
Integration timeout	50ms-29s (up to 300s Regional/Private)	30s hard	29s
APIs per region	600 Regional/Private; 120 Edge-optimized	600	600
Stages per API	10	10	10
Routes/resources per API	300	300	300
Custom domains (public)	120	120	120
Account throttle	10,000 rps / 5,000 burst	Same	Same (shared quota)
API keys per region	10,000	N/A	N/A
Usage plans per region	300	N/A	N/A
Cache sizes	0.5 GB - 237 GB	N/A	N/A

Files

ATTRIBUTION.mdAdded by AutoGineer908 B
LICENSELicence file added by AutoGineer9.9 KiB
NOTICELicence file added by AutoGineer89 B
SKILL.md19.3 KiB
references/architecture-patterns.md19.0 KiB
references/authentication.md9.4 KiB
references/custom-domains-routing.md8.5 KiB
references/deployment.md14.9 KiB
references/governance.md9.8 KiB
references/observability-analytics.md4.2 KiB
references/observability-logging.md11.2 KiB
references/observability-metrics-alarms.md5.5 KiB
references/performance-scaling.md9.0 KiB
references/pitfalls.md2.0 KiB
references/requirements-gathering.md14.8 KiB
references/sam-cloudformation.md7.8 KiB
references/sam-service-integrations.md22.5 KiB
references/security.md18.2 KiB
references/service-integrations.md24.4 KiB
references/service-limits.md11.5 KiB
references/troubleshooting.md14.5 KiB
references/websocket.md7.4 KiB

references/authentication.md

Authentication and Authorization

Decision Tree

Is this a WebSocket API?
  YES -> Lambda Authorizer (REQUEST type only on $connect; TOKEN type not
         supported; cached policy applies for entire connection, must
         cover all routes) or IAM (SigV4)
  NO ->
Is the consumer an AWS service or resource?
  YES -> IAM Authorization (SigV4)
  NO -> Is the consumer a browser-based app?
    YES -> Do you use Cognito?
      YES -> REST API: Cognito User Pool Authorizer
             HTTP API: JWT Authorizer (Cognito issuer)
      NO  -> Do you use another OIDC provider?
        YES -> HTTP API: JWT Authorizer
               REST API: Lambda Authorizer (validate JWT)
        NO  -> Lambda Authorizer (custom logic)
    NO -> Is this machine-to-machine (M2M)?
      YES -> Do you need certificate-based auth?
        YES -> mTLS (Regional custom domain + S3 truststore)
        NO  -> OAuth 2.0 Client Credentials Grant (Cognito + JWT/Cognito authorizer)
      NO -> Lambda Authorizer (most flexible)

IAM Authorization (SigV4)

Works for REST, HTTP, and WebSocket APIs (WebSocket: evaluated on $connect only)
Caller signs requests with AWS Signature Version 4
Best for: AWS-to-AWS service calls, Cognito identity pools, resources already integrated with IAM
Cross-account REST API: Requires BOTH IAM policy (caller account) AND resource policy (API account)
Cross-account HTTP API: No resource policies; use sts:AssumeRole to assume a role in the API account
Multi-region: SigV4 signatures are region-specific: the signing region must match the region receiving the request. In multi-region deployments with Route 53 failover or latency-based routing, clients signing for one region will get auth failures if routed to another. SigV4a (multi-region signing) is not supported by API Gateway. Workarounds: use a region-agnostic auth mechanism (Lambda authorizer, JWT) for multi-region APIs, or implement client-side retry logic that re-signs for the correct region on auth failure

Lambda Authorizers

REST API

TOKEN type: Receives a single header value (typically Authorization) as input. Returns IAM policy document. If the identity source header is missing, API Gateway returns 401 immediately without invoking the Lambda; the authorizer function never gets the chance to handle missing tokens
REQUEST type: Receives headers, query strings, stage variables, and context variables as input. Returns IAM policy document. When caching is enabled and identity sources are specified, a request missing any identity source returns 401 without invoking the Lambda
Both types must return principalId (string identifying the caller) alongside the policy document. Missing principalId causes 500 Internal Server Error
Response limits: IAM policy document max ~8 KB. Exceeding this or returning a malformed response causes 500 Internal Server Error (not 401/403), a common debugging pitfall
Caching: TTL default 300s, max 3600s. Cache key is the token value (TOKEN type) or identity sources (REQUEST type). When caching is enabled, the IAM policy returned by the first request is reused for subsequent requests with the same cache key. If that policy only covers specific resources (e.g., the path of the initial request), subsequent requests to other paths will be denied by the cached partial policy, causing hard-to-troubleshoot failures where clients intermittently cannot access parts of the API. Always generate IAM policies that cover the entire API when caching is enabled

HTTP API

Simple response format: Returns {isAuthorized: true/false, context: {...}}, much simpler than IAM policy
IAM policy format: Also supported for more complex authorization. When using IAM policy format with caching, the same full-API policy guidance from REST API applies; see REST API caching note above
Identity sources: $request.header.X, $request.querystring.X, $context.X, $stageVariables.X
Caching: Disabled by default (TTL=0), unlike REST API (TTL=300s). Add $context.routeKey to identity sources to cache per-route when enabling caching
Timeout: 10,000ms max

JWT Authorizers (HTTP API Only)

Validates: iss, aud/client_id, exp, nbf (must be before current time), iat (must be before current time), scope/scp (against route-configured scopes). Uses kid for JWKS key lookup. Request is denied if any validation fails
Only RSA-based algorithms supported (RS256, RS384, RS512). ECDSA (ES256, ES384, ES512) is not supported. If your IdP signs tokens with ECDSA, use a Lambda authorizer instead
Public key cached for 2 hours; account for this in key rotation
Token validation runs on every request (no result caching); only the JWKS public keys are cached (2 hours). This differs from REST API Cognito authorizer which caches the validation result
JWKS endpoint timeout: 1,500ms
Max audiences per authorizer: 50. Max scopes per route: 10
Use access tokens with scopes for authorization. ID tokens also work when no scopes are configured on the route, but access tokens are preferred for API authorization
Only supports self-contained JWTs; opaque access tokens are not supported. If your IdP issues opaque tokens by default, use a Lambda authorizer instead
Works natively with Cognito, Auth0, Okta, and any OIDC-compliant provider

Cognito User Pools (REST API)

Native authorizer type for REST APIs
When no OAuth scopes configured on the method: use ID token
When scopes configured: use access token
Set up: Create user pool, app client, configure scopes on resource server
Token revocation not enforced: The Cognito authorizer validates tokens locally (signature + claims) and does not check revocation status with Cognito. Revoked tokens (GlobalSignOut, AdminUserGlobalSignOut) are accepted until the token's exp time, as revocation is invisible to local validation regardless of caching. Separately, caching (default TTL 300s) means expired tokens may be accepted for up to the TTL duration after exp. For immediate revocation, use a Lambda authorizer with token introspection instead
M2M auth: OAuth 2.0 Client Credentials Grant (confidential app client with client ID + secret, custom resource server scopes). Also works with HTTP API JWT authorizer using Cognito as issuer

Resource Policies (REST API Only)

Four key use cases:

Cross-account access: Allow specific AWS accounts by specifying the account principal in the Principal field
IP filtering: Allow/deny CIDR ranges via aws:SourceIp (public) or aws:VpcSourceIp (private/VPC)
VPC restriction: Restrict to specific VPCs via aws:SourceVpc
VPC endpoint restriction: Restrict to specific VPC endpoints via aws:SourceVpce

Policy Evaluation

Evaluation depends on which auth type is combined with the resource policy:

Same account + IAM or Lambda authorizer: OR logic. If the auth mechanism allows, access is granted even if the resource policy has no matching statement (silent). An explicit Deny in the resource policy still wins
Same account + Cognito: AND logic. Both the Cognito authorizer and the resource policy must allow
Resource policy alone (no other auth): Must explicitly allow, otherwise request is denied
Cross-account: AND logic. BOTH resource policy AND caller auth must explicitly allow. A silent resource policy results in implicit deny. This applies regardless of auth type (IAM, Cognito, Lambda authorizer)
An explicit Deny always wins regardless of combination
Always redeploy the API after changing the resource policy

Mutual TLS (mTLS)

Truststore in S3 (PEM-encoded, max 1,000 certs, max 1 MB). Certificate chain max 4 levels deep; minimum SHA-256 signature, RSA-2048 or ECDSA-256 key strength
S3 bucket must be in the same region as API Gateway; enable versioning for rollback
Works with Regional custom domain names for REST and HTTP APIs. Edge-optimized custom domains do not support mTLS
WebSocket APIs do not support native mTLS; use CloudFront viewer mTLS instead (see references/security.md)
ACM certificate required for the API Gateway domain (ACM-issued or imported) for server-side TLS. Truststore accepts CA certificates from any source (ACM Private CA, commercial CA, self-signed root); just needs PEM format
Private APIs do not natively support mTLS. Use ALB as a reverse proxy in front: Client → ALB (mTLS verify with trust store) → VPC endpoint → Private API Gateway → backend. The ALB terminates the mTLS handshake, validates the client certificate, and forwards the request to the private API via the execute-api VPC endpoint
Disable default endpoint: Always set disableExecuteApiEndpoint: true when using mTLS; otherwise clients can bypass mTLS entirely by calling the default execute-api URL directly
CRL checks: API Gateway does not check Certificate Revocation Lists. Implement via Lambda authorizer checking against CRL in DynamoDB/S3
Certificate propagation to backend: Use Lambda authorizer to extract subject, return in context, inject as custom header via RequestParameters

API Keys

Not a primary authorization mechanism (easily shared/exposed)
Use with usage plans for throttling/quota enforcement only
Max 10,000 API keys per region (adjustable). Imported key values must be 20-128 characters
Key source: HEADER (default, x-api-key) or AUTHORIZER (Lambda returns key in usageIdentifierKey)
REST API only. HTTP API does not support API keys or usage plans

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server, Needs an API key

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

AWS Labs

Publisher

AWS Labs (Official)

Source

awslabs/agent-plugins · plugins/aws-serverless/skills/api-gateway · commit fbefb37

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
NOTICE (added by AutoGineer from NOTICE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by AWS Labs or AWS Labs.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download api-gateway.zip