What Is an API Gateway in .NET Core? Explained

An API gateway in .NET Core is a single entry point—built as an ASP.NET Core application—that sits in front of your backend services and handles routing, authentication, rate limiting, and response shaping before a request ever reaches your actual business logic. Instead of clients calling five different microservices directly, they call one .NET Core app, which forwards each request to the right place and returns a consistent response.

In practice, "API gateway in .NET Core" usually refers to one of two things: a reverse-proxy library like YARP (Yet Another Reverse Proxy) or Ocelot running inside an ASP.NET Core host, or a custom-built middleware pipeline that does the same job manually. Both approaches let you use familiar .NET tooling—dependency injection, middleware, configuration binding—to implement gateway behavior instead of adopting a separate infrastructure product like Kong or AWS API Gateway.

Why .NET Teams Build Their Own Gateway

Teams already invested in the .NET ecosystem often prefer a .NET Core gateway over a third-party product for a few concrete reasons:

• Shared tooling. The gateway uses the same logging, configuration, and dependency injection patterns as the rest of the stack, so there's no context-switching for the team.
• Fine-grained control. You can write custom middleware for things like request signing or header rewriting that a generic gateway product might not support out of the box.
• No extra infrastructure. A YARP-based gateway is just another ASP.NET Core app—deploy it the same way you deploy everything else, no separate managed service to provision.
• Cost. Self-hosting avoids per-request pricing that some managed gateway services charge.

The tradeoff is that you own the operational burden: scaling, patching, monitoring, and building features (like circuit breakers or distributed rate limiting) that come free with managed products.

YARP: Microsoft's Reverse Proxy Toolkit

YARP is the most common way to build an API gateway in .NET Core today. It's a library, not a standalone product, meant to be embedded in an ASP.NET Core project.

A minimal YARP gateway looks like this:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddReverseProxy()
    .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));

var app = builder.Build();
app.MapReverseProxy();
app.Run();

And the routing configuration in appsettings.json:

{
  "ReverseProxy": {
    "Routes": {
      "orders-route": {
        "ClusterId": "orders-cluster",
        "Match": { "Path": "/orders/{**catch-all}" }
      }
    },
    "Clusters": {
      "orders-cluster": {
        "Destinations": {
          "orders-api": { "Address": "https://orders-service.internal/" }
        }
      }
    }
  }
}

From here you add middleware for authentication, rate limiting, and logging using standard ASP.NET Core patterns. YARP handles the low-level proxying (connection pooling, header forwarding, load balancing across destinations), and you plug in the cross-cutting concerns yourself.

Ocelot: A Configuration-First Alternative

Ocelot predates YARP and takes a more configuration-driven approach, with built-in support for rate limiting, caching, and aggregation defined declaratively in JSON rather than code. It's a good fit if you want a gateway that's mostly configured rather than mostly coded, though YARP has become the more actively maintained option since Microsoft took over its development.

What a .NET Core Gateway Typically Handles

Regardless of which library you choose, the responsibilities are the same:

1. Routing — mapping incoming paths to the correct backend service or version.
2. Authentication — validating JWTs or API keys before requests reach downstream services.
3. Rate limiting — using ASP.NET Core's built-in Microsoft.AspNetCore.RateLimiting middleware to throttle abusive clients.
4. Aggregation — combining responses from multiple services into one payload for the client.
5. Observability — centralized logging and metrics for every request that passes through, regardless of which service handled it.

This is the same conceptual job any API gateway does—.NET Core just gives you the implementation surface.

When to Skip Building One

Building a gateway from scratch makes sense when you're proxying to internal microservices you control. It makes less sense when the thing you're actually trying to expose is a third-party AI provider, because you inherit a different set of problems: managing per-user keys, streaming responses correctly, tracking token usage, and enforcing per-seat limits—none of which YARP or Ocelot handle natively.

If your goal is specifically to turn Claude access into an internal HTTPS API for your team or product—rather than build general-purpose microservice routing—a purpose-built layer like SubToAPI covers that narrower case directly: it issues scoped application keys (sub_live_...), supports streaming and tool use, and gives you usage metadata per key without writing gateway middleware yourself. Check the quickstart to see how a request looks. For general microservice fan-out, though, a YARP or Ocelot gateway inside ASP.NET Core is still the right tool.

Getting Started

If you're building a .NET Core gateway from scratch, a reasonable path is:

• Start with YARP for basic routing and load balancing—it's actively maintained and integrates cleanly with ASP.NET Core middleware.
• Add authentication middleware early, before you add more routes, so every new route inherits the same security posture.
• Use ASP.NET Core's built-in rate limiting middleware rather than writing your own token-bucket logic.
• Centralize logging at the gateway level with a correlation ID so you can trace a request across every downstream service it touches.

questions

Is YARP the same as Ocelot? No. Both are .NET libraries for building reverse-proxy gateways, but YARP is developed and maintained by Microsoft and focuses on performance and extensibility through code, while Ocelot is community-maintained and leans more on declarative JSON configuration.

Do I need Kubernetes to run an API gateway in .NET Core? No. A YARP or Ocelot gateway is just an ASP.NET Core web app—it can run on a single VM, in a container, or behind IIS. Kubernetes helps with scaling and service discovery but isn't required.

Can a .NET Core gateway handle authentication for downstream services? Yes. It's common to validate JWTs or API keys once at the gateway and pass a trusted identity header downstream, so individual services don't each need to re-implement authentication logic.