method_not_allowed

What it means

HTTP 405 means the request reached an endpoint that does not accept the HTTP method you sent. The OneLifeVibe Platform API reports that case with the stable code method_not_allowed. The response body has an error object containing code, message, and hint. The message may be as short as "Use POST." or "Use GET or POST." Treat method_not_allowed as a signal that the path was reached but the verb was wrong.

Codes are stable across the API; messages can change. Match on code, never on the message. If your handler branches on text such as Use POST., a wording change can break it. Branch on method_not_allowed and read message and hint for diagnostic context.

Why you are seeing it

A common cause is sending a GET to an endpoint that only takes POST. Your HTTP client may default to GET when you omit the method, so check the actual method on the wire rather than the method you intended in your code.

Another cause is a mismatch between your client and the API documentation. An endpoint may take GET or POST, or only one of them, and your request uses a different verb. The code appears when the method is not accepted, not when the path is missing. For a missing or incorrect path, look at not_found.

How to fix it

Open the reference for the endpoint you are calling and use the method it lists. If the response message says Use POST., send POST. If it says Use GET or POST., pick the method that matches the operation you need. Set the method explicitly in your client.

After changing the method, send the request again with the same path and parameters. Do not keep retrying the same request unchanged; the response will remain method_not_allowed until the method matches what the endpoint accepts.

Use the hint and message fields to confirm what the endpoint expects, then update the call site or configuration that sets the method. If the path is also wrong, you may see not_found instead.

Handling it in code

Read the error object from the response body and check error.code. Handle method_not_allowed separately from other failures. During development, fail the request with a clear log line that includes the HTTP status, code, message, and hint. Do not parse the message to decide what to do.

Because codes are stable, you can map method_not_allowed to a specific action: fix the request method or surface a configuration error. Do not retry with the same method automatically. If you add a retry policy, trigger it only after the method has been corrected.

Keep the raw message and hint in logs so the next developer can see whether the endpoint wants POST or GET or POST. Match only on code, never on message.