Introduction

This ASP.NET Web API error means the framework found more than one controller action that appears valid for the same request. The fix is not to guess which one Web API will pick, because it refuses to guess; the fix is to make the route and action selection unambiguous.

Why the ambiguity happens

Classic Web API selects an action using the HTTP verb, route template, action name conventions, and parameter binding rules. If two actions can both satisfy the same incoming request, the selector throws the "multiple actions were found" error.

A common example is method overloading that looks obvious to a C# developer but not to the HTTP action selector.

1public class OrdersController : ApiController
2{
3    public IHttpActionResult Get(int id)
4    {
5        return Ok($"Order {id}");
6    }
7
8    public IHttpActionResult Get(string status)
9    {
10        return Ok($"Status {status}");
11    }
12}

Depending on the route and binding rules, requests can become ambiguous because both actions look like plausible GET targets.

Make the routes explicit

The safest fix is to stop relying on overloaded action names and give each route a unique template with clear constraints.

1[RoutePrefix("api/orders")]
2public class OrdersController : ApiController
3{
4    [HttpGet]
5    [Route("{id:int}")]
6    public IHttpActionResult GetById(int id)
7    {
8        return Ok($"Order {id}");
9    }
10
11    [HttpGet]
12    [Route("status/{status}")]
13    public IHttpActionResult GetByStatus(string status)
14    {
15        return Ok($"Status {status}");
16    }
17}

This version is unambiguous for both humans and the framework. One route clearly expects an integer identifier, and the other clearly expects a status segment under a different path.

Other common sources of conflict

Ambiguity can also come from attribute routes that overlap, optional parameters that blur two templates together, or mixing conventional routing with action overloads that differ only by parameter type. Query-string parameters can contribute too if two actions share the same route but depend on different optional arguments.

The underlying rule is simple: HTTP routing is not the same thing as C# overload resolution. If two endpoints look similar on the wire, Web API may not be able to tell them apart.

A practical debugging approach

When this error appears, inspect the controller as if you were the router:

1. what HTTP verb is the request using
2. what route template does it match
3. which actions are marked as candidates for that verb
4. which parameters could bind successfully

Usually the conflict becomes obvious once you stop thinking in terms of method signatures and start thinking in terms of URLs plus verbs.

If the controller is already using attribute routing, simplify the routes until each action has a clearly different public shape. If it is still using conventional routing, moving the ambiguous actions to explicit attribute routes is often the fastest cleanup. That makes the endpoint contract visible in the controller instead of hiding it in naming conventions and route defaults.

Common Pitfalls

• Overloading action methods by parameter type and expecting Web API to resolve them like normal C# methods.
• Defining overlapping attribute routes without constraints such as :int.
• Mixing conventional routes and attribute routes in a way that creates duplicate candidates.
• Relying on optional parameters for endpoint identity instead of using distinct route templates.
• Renaming methods but leaving the public HTTP shape ambiguous.

Summary

• The error means more than one action matches the same HTTP request.
• Classic Web API routing does not behave like C# overload resolution.
• Use distinct route templates, verb attributes, and route constraints to remove ambiguity.
• Avoid action overloads that differ only by parameter type or optional arguments.
• Debug the problem from the router's perspective: verb, path, and bindable parameters.