SWA Proxy Returning 405 Method Not Allowed for POST Request

Question

The backend API at https://changemanagement-backend-ahfre3hvgcerbrgp.canadacentral-01.azurewebsites.net/api/auth/login works correctly with POST when called directly. The Static Web App (SWA) at https://happy-dune-05915200f.6.azurestaticapps.net is configured with staticwebapp.config.json to proxy /api/* (including POST methods) to this backend.

The SWA "Application Configuration" view in the portal shows that it has parsed the rewrite rule correctly. However, when the frontend (served by SWA) makes a POST request to /api/auth/login, SWA returns a 405 Method Not Allowed with an Allow: GET, HEAD, OPTIONS header, and the browser does not seem to be sending an OPTIONS preflight request.

This indicates that the SWA proxy is not correctly applying the routing/method rules for the POST request. Additional support from Azure may be needed to address this issue.

Answer 1

Hello Ian Thomson,

First, SWA needs a special configuration file named staticwebapp.config.json right beside your built index.html. During your build or deployment, you should see a message like below.

Copying 'staticwebapp.config.json' to build output

If you don’t see that, SWA never picked up the file and will ignore any proxy rules you wrote. Make sure the file actually lives in the final folder that SWA publishes.

Inside that file, SWA expects you to use the word methods, not “allowedMethods.” If you write “allowedMethods,” SWA will act as if you only asked it to allow GET, HEAD, and OPTIONS, and it will reject POST. You also must use a placeholder called {*restOfPath} so that SWA knows to take whatever comes after /api/ and append it to the backend URL exactly. If you use any other placeholder, SWA won’t match the rule at all, and you’ll still see “No routes to display” in the portal.

A simple, correct staticwebapp.config.json might look like this check below.

{

  "routes": [

    {

      "route": "/api/*",

      "methods": ["GET","POST","PUT","DELETE","OPTIONS","HEAD","PATCH"],

      "rewrite": "https://changemanagement-backend-ahfre3hvgcerbrgp.canadacentral-01.azurewebsites.net/api/{*restOfPath}"

    }

  ],

  "navigationFallback": {

    "rewrite": "/index.html",

    "exclude": [

      "/static/css/*",

      "/static/js/*",

      "/static/media/*",

      "*.{png,jpg,gif,svg,ico}"

    ]

  }

}

After you save and push that file, wait for your SWA build to finish. Then check under Configuration < Route Rules in the Azure portal. You should see your /api/* rule with all the HTTP verbs listed. If it still says, “No routes,” SWA isn’t seeing your file, so you’ll need to double-check where you placed it.

Once SWA is configured to forward POST, PUT, DELETE, and so on, the browser will send a small “preflight” check called an OPTIONS request before the actual POST. Even though SWA will forward that OPTIONS request to your backend, your backend must answer it without a 405 error—otherwise, the browser never moves on to POST. To test this, open a terminal and run exactly this command:

curl -i -X OPTIONS \

  -H "Origin: https://happy-dune-05915200f.6.azurestaticapps.net" \

  -H "Access-Control-Request-Method: POST" \

  https://changemanagement-backend-ahfre3hvgcerbrgp.canadacentral-01.azurewebsites.net/api/auth/login

If the App Service is set up correctly, you should see - HTTP/1.1 200 OK

But if you see 405 Method Not Allowed, your server is refusing that preflight check. In that case, you need to add CORS support or an OPTIONS handler in the code so that when the browser asks, “Can I send a POST?” your server replies “Yes, you can.” For example, in ASP .NET Core you might call app.UseCors(...) so that OPTIONS requests return 200 with the right headers. In Node or Express you might use the cors middleware or add a small route like below.

app.options("/api/auth/login", (req, res) => {

  res.set({

    "Access-Control-Allow-Origin": "https://happy-dune-05915200f.6.azurestaticapps.net",

    "Access-Control-Allow-Methods": "GET, POST, OPTIONS, PUT, DELETE",

    "Access-Control-Allow-Headers": "Content-Type, Authorization"

  });

  return res.sendStatus(200);

});

Once the backend answers OPTIONS with a 200 and the CORS headers, SWA can forward the actual POST. To confirm everything is working, try sending a POST directly through your SWA domain (this skips the browser and any cached CORS decisions).

curl -i -X POST \

  -H "Content-Type: application/json" \

  -d '{"username":"alice","password":"secret"}' \

  https://happy-dune-05915200f.6.azurestaticapps.net/api/auth/login

If SWA is forwarding correctly and the backend is accepting POST, you will see whatever response the App Service sends back no more 405 error. Hope this helps!

If the answer is helpful, please click Accept Answer and kindly upvote it. If you have any further questions, please reply back.