Fix 405 method not allowed on API Gateway

Quick Answer: The 405 Method Not Allowed error on API Gateway indicates that the HTTP method used in the client request (e.g., POST) is not explicitly configured or enabled for the requested resource path. The most likely cause is a mismatch between the client's HTTP verb and the API Gateway method setup. First, verify the API Gateway resource's method configuration in the AWS Console. Ensure the specific HTTP method (e.g., GET, POST) is defined and integrated correctly. An expected result is the API Gateway successfully routing the request to the backend integration without a 405 error.

What Causes This Error

• HTTP method not defined for the resource path in API Gateway (e.g., only GET is defined, but a POST request was sent).
• Incorrect or missing integration request configuration for the specific HTTP method, leading API Gateway to reject the method before forwarding.
• Proxy integration misconfiguration where the backend service only supports a subset of HTTP methods, and API Gateway isn't filtering or transforming.
• CORS preflight (OPTIONS) method not explicitly enabled or configured for the resource, causing 405 for cross-origin requests.
• Lambda Authorizer or custom authorizer rejecting the request due to method-specific policy, even if the method is defined.
• Stage-level or resource-level WAF (Web Application Firewall) rule blocking specific HTTP methods.

Step-by-Step Fixes

Fix 1: Verify and Configure API Gateway Resource Methods

Navigate to the API Gateway console, select your API, and then the specific resource path.,Under the 'Methods' section, ensure that the HTTP method you are trying to use (e.g., POST, PUT) is explicitly listed and configured.,If missing, click 'Actions' -> 'Create Method', select the correct HTTP method, choose an integration type (e.g., Lambda Function, HTTP), and save the configuration.

Fix 2: Inspect Integration Request for Method Mismatch

For the affected method (e.g., POST) on your resource, click on 'Integration Request'.,Verify that the 'Integration type' and 'Lambda Function' or 'HTTP Endpoint' are correctly specified for that particular method.,Ensure that any 'Mapping Templates' are correctly configured for the method's payload, as misconfiguration here can sometimes manifest as a method rejection.

Fix 3: Enable and Configure OPTIONS Method for CORS

If the 405 occurs during a cross-origin request (often indicated by a preflight OPTIONS request failing), select the resource path.,Click 'Actions' -> 'Enable CORS'. Follow the prompts to add the OPTIONS method, configure allowed origins, headers, and methods.,Deploy the API to apply the CORS configuration changes.

Fix 4: Review Backend Service Method Support and Proxy Integration

If using a proxy integration (e.g., Lambda Proxy, HTTP Proxy), ensure your backend service (Lambda function, HTTP endpoint) is actually capable of handling the requested HTTP method.,For Lambda Proxy, inspect your Lambda function's code to confirm it handles 'event.httpMethod' for the expected verbs.,For HTTP Proxy, test the backend endpoint directly with the problematic HTTP method to isolate if the issue is with API Gateway or the backend.

Fix 5: Check WAF Rules and Authorizer Policies

If you have AWS WAF integrated with your API Gateway, navigate to the WAF console and inspect any Web ACLs associated with your API.,Look for rules that might be blocking specific HTTP methods (e.g., 'MethodMatch' rules that deny anything but GET/POST).,If using a Lambda Authorizer, review its code and associated IAM policies to ensure it's not rejecting requests based on 'event.methodArn' or 'event.httpMethod' for the specific method.

Advanced Fixes

Advanced Fix 1: Debugging with API Gateway Access Logging and CloudWatch

Enable full execution logging for your API Gateway stage in CloudWatch Logs, ensuring 'Log full requests/responses data' is checked.,After reproducing the 405 error, analyze the CloudWatch Logs for the 'Method' and 'Resource' fields to confirm what API Gateway perceived the request to be.,Look for specific entries like 'Method completed with status: 405' and preceding lines for clues on why the method was rejected (e.g., 'Endpoint request URI: N/A', indicating no matching integration).

Advanced Fix 2: Using X-Ray Tracing for Integration Path Analysis

Enable AWS X-Ray tracing for your API Gateway stage and the integrated backend service (e.g., Lambda function).,Reproduce the 405 error and then navigate to the X-Ray console to view the service map and traces.,While a 405 typically occurs before backend integration, X-Ray can confirm if any part of the integration (like an authorizer) was invoked and rejected the request, providing detailed subsegment timing and error messages.

FAQs

Q: Why does my API work with GET but not POST, even if I defined both?

A: This often happens if the 'Integration Request' for the POST method is not correctly configured, even if the method itself is defined. Ensure the POST method points to the correct backend integration (e.g., Lambda function or HTTP endpoint) and that any necessary mapping templates are in place for the request body. A common mistake is defining the method but leaving its integration unconfigured or misconfigured.

Q: I enabled CORS, but I'm still getting 405 for OPTIONS requests. What's wrong?

A: Even after enabling CORS, you must ensure the API is deployed to propagate the changes. Also, confirm that the 'Access-Control-Allow-Headers' and 'Access-Control-Allow-Methods' in the OPTIONS method's 'Integration Response' and 'Method Response' are correctly configured to include the headers and methods your client is using. Sometimes, a custom authorizer might also block OPTIONS requests if not explicitly allowed.

Q: Does a 405 error mean my Lambda function isn't being invoked?

A: Yes, typically. A 405 'Method Not Allowed' error occurs at the API Gateway level before the request is forwarded to your backend integration (like a Lambda function). It means API Gateway itself rejected the request because the HTTP method was not configured for that resource path. If your Lambda was invoked, you would likely see a 5xx error (if the Lambda failed) or a 2xx response.

Q: Can API Gateway's greedy path variables cause a 405?

A: Yes, if not carefully managed. If you have overlapping resource paths, such as '/items/{id}' and '/items/specific', API Gateway's routing logic might incorrectly match a request to a resource that doesn't have the requested HTTP method defined. Always test specific paths and ensure the most specific path is evaluated first, or use distinct path structures.

Related Errors