Fix 'Endpoint Only Accepts POST Requests' (HTTP 405) Error

You’re staring at a red error screen, perhaps right in the middle of a crucial login session or a critical API integration. The message is blunt: “The endpoint only accepts POST requests. Received a GET request.” If you’ve seen the specific code AADSTS900561 or a generic HTTP 405 Method Not Allowed, you’re likely feeling a mix of frustration and confusion. You weren’t trying to "hack" the system; you were just trying to log in or send data, yet the server rejected you.

This isn’t just a quirky glitch. In my fifteen years of debugging production systems, I’ve learned that this error is rarely about the HTTP verb itself being "wrong" in a vacuum. It’s almost always a symptom of a deeper configuration mismatch, a security protocol violation, or a stale browser state. Whether you’re a developer hitting a wall with Axios or a user locked out of Microsoft 365, the root cause lies in how RESTful API constraints and OAuth2 security flows handle sensitive data.

In this guide, we aren’t going to just tell you to "clear your cache" and hope for the best. Instead, we’ll break down the "why" behind the restriction, then provide a structured decision tree to fix the issue—whether you’re on the user side dealing with browser cookies or on the developer side auditing your code and Azure AD configuration. By the end, you’ll know exactly how to interpret HTTP status codes and fix 405 method not allowed errors without guesswork.

Understanding HTTP 405: Why RESTful APIs Reject GET Requests

Before we jump into the fixes, it’s vital to understand the mechanism. Many developers assume that any endpoint can accept any HTTP method, but RESTful API constraints dictate that specific verbs map to specific actions. When you encounter http 405 method not allowed, the server is saying, "I know where this resource is, but I do not accept the action you are requesting."

The Security Rationale Behind POST-Only Endpoints

To understand why you’re getting blocked, look at RFC 7231, which defines HTTP methods. GET is defined as "safe" and "idempotent." This means that sending a GET request should not result in any side effects on the server and can be safely repeated. Because GET requests are inherently visible—they appear in URL bars, are logged by servers, cached by proxies, and shared in social media links—they are strictly forbidden from carrying sensitive data like credentials, session tokens, or client secrets.

This is why OAuth2 protocols, such as those used by Microsoft Identity Platform, separate their flows. The Authorization Code Flow uses a GET request to redirect the user to the authentication endpoint (/authorize). This step is public; it’s just telling the browser where to go. However, the next step—exchanging the authorization code for an access token—happens at the /token endpoint. This endpoint must accept POST requests. If you send a GET request to /token, the server will reject it with a 405 or a specific error like AADSTS900561, because transmitting the code and client secret via URL query parameters would expose them to anyone looking over your shoulder or analyzing server logs.

It’s also important to distinguish this from a 404 error. A 404 means the server cannot find the resource. A 405 means the server found the resource, but the "verb" (HTTP method) you used is forbidden. This distinction is crucial for debugging: if you’re getting a 405, the URL is likely correct, but the request structure is wrong.

Troubleshooting AADSTS90056: User-Side Fixes for Microsoft 365

If you’re not a developer and are simply trying to log into Office 365, Teams, or a company portal, you’re likely hitting fix 405 method not allowed error scenarios caused by browser state. Microsoft’s identity services rely on a complex handshake of cookies and redirects. If that handshake breaks, the browser might fall back to a GET request where a POST is expected.

Browser Cache and Third-Party Cookie Diagnostics

In my experience, over 80% of end-user 405 errors on Microsoft properties are related to stale SSO cookies or blocked third-party cookies. Modern browsers are aggressive about privacy, often blocking the cross-site tracking that the OAuth flow depends on.

Here’s how to isolate this:

1. Test in Incognito Mode. Open a Private/Incognito window and try to log in. If it works, your standard profile has corrupted cookies. If it fails, the issue might be network or account-specific.
2. Clear Specific Cookies. Don’t just clear "all" data; that’s cumbersome. Target the login.microsoftonline.com domain.
   • Chrome/Edge: Go to Settings > Privacy and security > Cookies and other site data > See all sites and data they’ve stored. Search for microsoft.com and delete the entries.
   • Firefox: Go to Settings > Privacy & Security > Cookies and Site Data > Manage Data. Filter for microsoft and remove.
3. Allow Third-Party Cookies for Auth. Sometimes, enterprise policies or extensions block the cross-domain cookies needed for the final POST step. Temporarily allow third-party cookies for login.microsoftonline.com to test. If that resolves it, you’ve found the culprit.

Verifying Microsoft Service Status

If clearing cookies doesn’t help, the issue might not be you. Microsoft’s identity platform is global and complex. Transient outages can cause redirects to fail unexpectedly. Before assuming your configuration is broken, check the Azure Status Dashboard. Look for any incidents in the "Microsoft Entra ID" service. If there’s an active incident, the 405 error might be a side effect of a degraded service state. In these cases, persistence and waiting are your best strategy. Distinguish between a persistent configuration error (which will happen every time you try) and a temporary service disruption (which might resolve in an hour).

Developer Deep Dive: Fixing 405 Errors in API Code

If you’re building the application, the error axios gets 405 method not allowed is a direct result of your client-server communication mismatch. You are likely sending the wrong HTTP method to the wrong endpoint, or your headers are causing the server to reject the request before it even processes the method.

Correcting HTTP Method Mismatches in JavaScript and Python

A common pitfall is relying on default behaviors. For instance, in JavaScript, fetch() defaults to GET. If you forget to specify the method when sending data, the server will reject it if it expects a POST. Similarly, in Python, if you pass data to requests.get(), it will raise an error or behave unexpectedly.

Incorrect JavaScript (Axios):

// This will fail if the endpoint expects a POST
axios.get('https://api.example.com/resource', {
  params: { data: 'value' } // Query params are part of GET
});

Corrected JavaScript (Axios):

// Ensure you use POST and send JSON in the body
axios.post('https://api.example.com/resource', { data: 'value' }, {
  headers: {
    'Content-Type': 'application/json'
  }
});

Python Requests Pitfall: Many developers confuse params (which go into the URL query string) with data or json (which go into the body).

import requests

response = requests.get('https://api.example.com/token', json={'code': 'abc'})

response = requests.post('https://api.example.com/token', json={'code': 'abc'})

Always check your API documentation. If the endpoint is an action (like "create", "update", or "exchange"), it likely requires POST, PUT, or PATCH. If it’s a retrieval, it’s GET. When in doubt, use POST for anything involving secrets.

Auditing OAuth2 Configuration and Redirect URIs

If you’re using Azure AD (Entra ID), configuration drift is the enemy. I’ve seen teams spend days debugging code when the issue was simply a http vs. https mismatch in their appsettings.json or environment variables.

1. Verify the Protocol. Ensure your authentication URLs start with https://login.microsoftonline.com. Using http will result in immediate rejection.
2. Match Redirect URIs Exactly. The URI registered in the Azure Portal must match the URI used in your code character-for-character. A missing trailing slash or a www difference will break the flow, often resulting in weird redirects that end in 405 errors.
3. Check Tenant Consent. Ensure the app is registered and consented to in the correct tenant. If the app hasn't been consented, the redirect flow may fail in unexpected ways, masking the real issue as a method not allowed error.

Handling POST-Only Constraints in Frameworks: Curl, Nginx, and Strapi

Sometimes the issue isn't in your application code, but in how you're testing it or how it's served. curl error endpoint only accepts post is a frequent search term because developers often use cURL to debug APIs but forget that cURL defaults to GET.

Testing Endpoints with cURL and Postman

When you type curl https://api.example.com/resource, you are sending a GET request. To test a POST-only endpoint, you must explicitly override the method.

curl https://api.example.com/token

curl -X POST https://api.example.com/token \
  -H "Content-Type: application/json" \
  -d '{"client_id": "abc", "code": "xyz"}'

In Postman, ensure you are not using "Auto" for the method. Explicitly select "POST" from the dropdown. If you’re getting a 405 in Postman, double-check that your "Send Body" is set to "raw" (JSON) and not "urlencoded" if the API expects strict JSON parsing.

Server-Side Configurations: Nginx and Strapi

If you’re hosting your own API, your reverse proxy might be the culprit. Nginx can be configured to restrict methods. Check your nginx.conf for directives like:

location /api/ {
    # This might be blocking POST if misconfigured
    limit_except GET; 
    proxy_pass http://backend;
}

If you see limit_except GET;, that’s why your POST requests are failing with a 405. Remove that line or add POST to the allowed list.

For Strapi users, custom routes can sometimes be defined incorrectly. If you’ve created a custom controller but didn’t specify the HTTP method in the routing configuration, Strapi might default to GET. Ensure your routes.json explicitly maps the POST method to your controller function.

Common Causes You're Overlooking: Webhooks and Auth Masks

There’s a subtle class of errors where a 405 response is actually a mask for an authentication failure. This is particularly common in webhook configurations.

When 405 Errors Mask Authentication Issues

Many payment processors and SaaS platforms (like Stripe or Slack) use webhooks that strictly require POST requests with specific signature headers. If you’re using a browser or a simple tool to "test" the webhook by loading the URL (which sends a GET request), the server will return a 405. It’s not that the endpoint is broken; it’s that you’re using the wrong tool to simulate the event.

Similarly, some APIs are designed to return a 405 instead of a 401 or 403 when the request structure is invalid. For example, if a CSRF token is missing, the security middleware might reject the entire request verb before checking authentication. If you see a 405 and you’re certain your method is correct, look at the request headers. Are you missing a required X-CSRF-Token or Authorization header? In my experience, adding the correct headers often turns a mysterious 405 into a valid 200 OK.

Frequently Asked Questions

Why does my API return 405 when I use GET? A 405 error indicates that the server recognizes the resource URL but does not allow the HTTP method you are using. In the context of sensitive data exchange, like OAuth2 token endpoints, the server is designed to reject GET requests to prevent credentials from being exposed in URLs. You should switch to POST for any operation that modifies state or handles secrets.

How to fix AADSTS900561 error in Office 365? If you are a user seeing this error, try three quick fixes: 1) Clear your browser cookies for login.microsoftonline.com, 2) Ensure third-party cookies are allowed for authentication domains, and 3) Check if it’s a transient Microsoft outage. For developers, verify that your app’s redirect URI matches the Azure AD registration exactly and that you are using HTTPS.

Can I convert a GET request to a POST request in JavaScript? Yes. You can explicitly set the method in fetch or axios. For example: fetch(url, { method: 'POST', body: JSON.stringify(data), headers: { 'Content-Type': 'application/json' } }). Remember that changing the method often requires changing how data is sent (from query params to body).

What is the difference between 404 and 405 errors? A 404 "Not Found" error means the server could not find the requested resource at that URL. A 405 "Method Not Allowed" error means the resource exists, but the specific action (GET, POST, etc.) is forbidden by the server. If you get a 405, your URL is likely correct, but your request type is wrong.

Conclusion

Encountering the message "the endpoint only accepts POST requests" is rarely a sign of a broken system; it’s usually a security feature working as intended. The key to resolving HTTP 405 errors lies in understanding the intent of your request. If you’re a user, the fix is often as simple as clearing stale cookies or allowing necessary third-party authentication. If you’re a developer, the solution usually involves auditing your HTTP method usage, ensuring your OAuth2 redirect URIs are precise, and checking your server configurations for hidden method restrictions.

Don’t just suppress the error. Use proper error handling logging to capture the full request and response. This will help you catch these mismatches in production before they impact your users. Remember, a 405 is a conversation between your client and the server. Learn to listen to what it’s saying, and the fix will become obvious.

---

Want to go deeper? Download our free 'OAuth2 Configuration Checklist' to audit your app registration, or check our latest tutorial on handling CORS errors in modern web apps to ensure your frontend and backend are speaking the same language.