For each API endpoint, define the exact set of HTTP methods it accepts. Return HTTP 405 Method Not Allowed (with an Allow header listing permitted methods) for any method outside that set.

• GET /api/users — only GET. DELETE, PUT, POST, PATCH → 405

• POST /api/orders — only POST. GET, DELETE → 405

• GET /api/products/{id} — GET and PUT for update. DELETE only if admin role (checked in the handler). POST → 405

Implement at the routing layer: most frameworks support method-level routing (router.get(), router.post()). Unregistered methods return 405 automatically. Verify this behavior — some frameworks return 404 instead of 405, which hides the route existence.

Development and testing often add methods that shouldn’t exist in production: DELETE /api/users for resetting test data, PUT /api/config for updating settings during demos. These methods are added temporarily and never removed. CI/CD should include a test that verifies only expected HTTP methods return 2xx/3xx responses — any unexpected method returning success is a deployment failure.

The OPTIONS method is used for CORS preflight checks and is typically handled automatically by your framework. Configure it to return only the methods your endpoint actually accepts — don’t return a generic list of all HTTP methods. An accurate OPTIONS response is a feature; an inaccurate one that advertises methods the endpoint doesn’t support is a misconfiguration.