Fixed: "Failure to infer one or more parameters" in an ASP.NET Core Minimal API
Every request to my minimal API answered 500, and the log said Failure to infer one or more parameters. The message includes a small table, and one row in it had the answer: clock | UNKNOWN. My endpoint asked for a TimeProvider, and nothing had registered one. One line in Program.cs fixed it.
What I Was Doing
An endpoint in a .NET 10 minimal API gets the current time from .NET's TimeProvider, so it takes one as a parameter:
private static async Task<Results<Created<CategoryResponse>, ProblemHttpResult>> CreateAsync(
CategoryRequest request,
InventoryDbContext db,
TimeProvider clock,
CancellationToken cancellationToken)
Program.cs didn't have a line for it. The project built with no errors, and the API started. I sent a request:
POST http://localhost:5190/api/v1/categories
Content-Type: application/json
{
"name": "X"
}
What I Expected
201 Created, and the time from clock.GetUtcNow() in the response.
What I Got
fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1]
An unhandled exception has occurred while executing the request.
System.InvalidOperationException: Failure to infer one or more parameters.
Below is the list of parameters that we found:
Parameter | Source
---------------------------------------------------------------------------------
request | Body (Inferred)
db | Services (Inferred)
clock | UNKNOWN
Did you mean to register the "UNKNOWN" parameters as a Service?
The response was a 500, with the same text. And it wasn't only this endpoint: /health/live and every other address failed the same way.
What I Checked
The table. It lists every parameter of the failing endpoint and where ASP.NET Core thinks it comes from. request comes from the JSON body. db is a service. clock is UNKNOWN. Interestingly, cancellationToken isn't in the table: it's handled separately, as the parameter binding page explains, in its list of "special types".
How a parameter gets its source. The same page lists the "Supported binding sources": route values, query string, header, body, form values and "Services provided by dependency injection". A service only counts when it's in the container. TimeProvider is a class in .NET, but ASP.NET Core doesn't register it for you.
Why it fails for every request. The endpoints are built together the first time any request needs them. One endpoint that can't be built stops them all, so a healthy-looking /health/live fails too. That's why the API starts without a complaint.
Why It Happens
Minimal APIs decide where each parameter comes from by looking at its type and at the registered services. A type that isn't a service, and isn't something it can read from the request, has no source. ASP.NET Core can't guess what you meant, so it refuses to build the endpoint, and the message suggests the likely cause: "Did you mean to register the "UNKNOWN" parameters as a Service?"
The Fix
Register the service, above var app = builder.Build();:
// The clock. Code asks for it instead of calling DateTime.UtcNow directly.
builder.Services.AddSingleton(TimeProvider.System);
TimeProvider.System is the real clock, and one shared instance is safe, so a singleton fits. For your own classes, register them the same way, with AddScoped, AddTransient or AddSingleton.
After the Fix
The endpoint works now. Here it is creating a category:
POST http://localhost:5190/api/v1/categories
Content-Type: application/json
{
"name": "Cables"
}
HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8
Location: /api/v1/categories/1
{
"id": 1,
"name": "Cables",
"createdAtUtc": "2026-11-04T10:48:37.000261Z"
}
Common Mistakes
| Mistake | What happens | Do this instead |
|---|---|---|
| Reading only the first line of the message | You miss the table that names the parameter | Look for UNKNOWN in the table |
Adding [FromServices] without registering the service | The error changes to "No service for type" | Register the service |
| Assuming a type from .NET is already registered | Some are, such as ILogger<T>, and many aren't, such as TimeProvider | Check, or register it yourself |
| Testing only the endpoint you changed | Every endpoint fails until this one is fixed | Fix this first, then test the rest |
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
A parameter is listed as UNKNOWN | Its type isn't a registered service | Register it |
request is listed as Body (Inferred) on a GET | A class parameter on a GET, which gets a different message | See the body inferred post |
Your own class is listed as UNKNOWN | It's registered in another assembly's method that never ran | Call that method in Program.cs |
Every address answers 500, even health checks | One endpoint can't be built | Read the table in the log |
FAQ
Why does the build succeed?
The compiler checks that the types exist. Which services are registered is only known when the app runs.
Could I use DateTime.UtcNow instead?
Yes, and then there's nothing to register. How to Use TimeProvider Instead of DateTime.UtcNow shows what the service gives you in return.
Conclusion
"Failure to infer one or more parameters" means ASP.NET Core can't tell where an endpoint parameter comes from. The table in the message names it: look for UNKNOWN. It's almost always a service that was never registered, so add it to builder.Services. Until you do, every endpoint in the app fails, not only that one.
Additional Resources
- Parameter binding in Minimal API apps — how each parameter gets its source.
- What is TimeProvider? — the clock used here.
