Best practice to prevent api routes falling back to index.html

With the sample blazor wasm app downloaded from I can’t hit the api endpoints via the browser; they all fallback to a page not found on index.html.

What is the best practice for preventing this behaviour?
Is it possible to host the api on a different port?

When it’s deployed our Blazor WASM is statically hosted on a CDN:

Which is separate from the .NET API Server which is hosted on:

But this isn’t the case when running from localhost which should call your APIs when they exist, as-is required for the template to function. Are you saying you can’t call server routes? e.g:


Are you running the correct Blazor Host project? i.e. <MyApp> as opposed to <MyApp>.Client

What’s the HTTP Request/Response headers + Request/Response DTO you’re trying to call?

1 Like

Yeah, the problem was that I was running <MyApp>.Client, not <MyApp>. Thanks - I should have thought of that tbh.

How can we run <MyApp> to get access to the endpoints but still use dotnet watch to make use of the hot reloads during development?

The MyApp host project is the .NET server project which hosts the client WASM UI, whereas running the client project just runs the UI sans .NET Server APIs.

Yeah, so it’s not possible to get hot reload on the UI whilst serving the endpoints via the .net server project?

Not related, you should always run the MyApp Server project if your client needs it.

Hot reload with Blazor WASM is a mixed bag which sporadically works, usually works when you first open your project then stops working for me a bit later. The Hot Reload in Blazor Server provides a much nicer dev UX.

1 Like

OK, understood thanks. Must admit - we’ve found similar behaviour where hot reload gets flakey over time.

We’re changing from a servicestack/angular stack to servicestack/blazor-wasm so got quite a bit to learn… thanks for the continued support and help

1 Like