Skip to content

Method Not Allowed

URI: https://docs.ankatech.co/errors/method-not-allowed
HTTP Status: 405 Method Not Allowed

When you see this

The platform answers 405 in two situations, and the two responses differ:

  • The method is outside the platform's method set. Every service admits exactly GET, POST, PUT, PATCH, DELETE, OPTIONS and HEAD. Any other method (PROPFIND, TRACE, a lower-case get, …) is refused on every endpoint, before authentication, so the answer is the same with or without a token.
  • The endpoint does not support the method. The method is one of the seven, but the endpoint does not map it (for example, a DELETE where only GET is allowed).

Common Causes

  • Using POST/PUT/PATCH/DELETE on an endpoint that only exposes GET.
  • A typo in the request that changed the intended method, or a method name sent in lower case (method names are case-sensitive).
  • Calling a collection endpoint with a method reserved for item endpoints (or vice versa).
  • An out-of-date client or SDK that targets a method the API no longer accepts.
  • A tool or scanner that sends WebDAV or diagnostic methods such as PROPFIND or TRACE.

Response Example

A method outside the platform set:

HTTP/1.1 405 Method Not Allowed
Allow: GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD
Content-Type: application/problem+json

{
  "type": "https://docs.ankatech.co/errors/method-not-allowed",
  "title": "Method Not Allowed",
  "status": 405,
  "detail": "The HTTP method is not allowed.",
  "timestamp": 1790677200
}

This response is written before the request is attributed to anyone, so it carries only these five members. The detail is the same for every method and never repeats the method you sent; there is no instance, no correlation member in the body, and no X-Correlation-Id response header. Allow lists the whole platform set.

A method the endpoint does not support:

HTTP/1.1 405 Method Not Allowed
Allow: GET, POST
Content-Type: application/problem+json

{
  "type": "https://docs.ankatech.co/errors/method-not-allowed",
  "title": "Method Not Allowed",
  "status": 405,
  "detail": "Request method 'DELETE' is not supported for this endpoint. Supported methods: GET, POST",
  "instance": "/api/v3/keys",
  "correlationId": "550e8400-e29b-41d4-a716-446655440000",
  "timestamp": 1730000000
}

Content-Type: application/problem+json — both responses follow RFC 9457 Problem Details.

Allow is sent on the 405 the platform returns, as RFC 9110 §15.5.6 requires. On the method-set 405 it lists the platform set. On the per-endpoint 405 it lists the methods that endpoint supports: Admin API, Core API, Audit API and the Documentation Aggregator always send it, empty when no supported method is known (an empty Allow states that the resource allows no method); Auth API, PQC Handshake API and the License Server send it whenever the supported methods are known, which is the case on every mapped path.

On the per-endpoint 405, the correlation member's placement depends on which service answered. The example above shows the top-level correlationId emitted by Core API and PQC Handshake API. Admin API and Audit API nest a requestId under extensions instead, and Auth API and the License Server carry no correlation member in the body at all — the X-Correlation-Id response header is present on this response. See where extension members live.

Every service on the platform answers 405 with this problem type, on any endpoint, rather than a generic 500. If you receive a 5xx for what turns out to be a method mismatch, that is a defect worth reporting — a 5xx tells an integrator the server is broken and invites a retry of a request that only the caller can fix.

Refusals answered before the API. A request through the public entry point can be refused before it reaches a service, and then the answer is not this problem document: TRACE and CONNECT are answered with the proxy's own 405 page, and the authentication endpoints that restrict their methods at the entry point (the token, introspection, revocation and logout endpoints, among others) refuse any other method there with 403.

How to Resolve

  1. Check the Allow response header — it lists the methods the endpoint accepts (or, when the method is outside the platform set, the seven methods the platform admits).
  2. Confirm the correct method and path in the Developer Hub Reference.
  3. Update your client or SDK to the current API surface and re-submit the request with the supported method.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.