Why ServiceStack

ServiceStack is a batteries-included framework for building typed, message-based APIs in .NET.

Most frameworks give you a way to return JSON from a method. ServiceStack starts one level up: you describe what the message is, and everything downstream - the routes, the docs, the validation, the admin UIs, the native clients, the AI tool definitions - is generated from that single description.

The result is a framework where adding a capability usually means adding an attribute, not adding a project.

One contract, everything else generated

Here is a complete, working, queryable, secured API:

[ValidateIsAuthenticated]
[Description("Find bookings matching the specified criteria")]
public class QueryBookings : QueryDb<Booking>
{
    public int[] Ids { get; set; }
}

That single Request DTO gives you a REST API with filtering, paging and sorting, an executable API Explorer UI, a portable JSON Schema, an entry in your OpenAPI spec, a Locode CRUD App, an AI-callable tool and native typed clients in 15 languages - with no Service implementation, no controller, no DTO mapping and no SDK project.

One Service, many consumers

Write the contract. Skip the rest.

The clearest way to see the value is to compare what you write against what you'd otherwise have to write - and keep writing, for every platform, forever.

Rich UIs your APIs get for free

Every ServiceStack App ships with capable, authorized management UIs that are generated from your APIs at runtime. There is nothing to install, no separate admin project to maintain, and no drift between your API and the tools used to operate it.

INFO

All Admin UIs respect your App's existing authentication and authorization - users only see the screens and actions their roles allow.

Typed clients in 15 languages

Add ServiceStack Reference reads the metadata your App already publishes and generates a single native source file of DTOs for the target language, paired with an idiomatic Service Client that understands the contract: response types, routes, HTTP methods, authentication, structured errors, validation failures and AutoQuery conventions.

.NET
C# · F# · VB.NET
Web & Scripting
TypeScript · JavaScript · Python · PHP · Ruby
Mobile
Swift · Java · Kotlin · Dart
Cloud & Systems
Go · Rust · Zig

Two commands in any language - add the client, then generate the DTOs:

Re-run the same command whenever your API changes. New fields appear in the generated DTOs; removed or renamed members become compile errors in the consuming App instead of runtime surprises in production.

TIP

This is the opposite of the SDK treadmill. There's no per-platform SDK repo to version, publish and document - the contract is the SDK.

AI-native, without an AI backend

The metadata that generates typed clients also describes your APIs well enough for a model to use them. So instead of building a parallel "AI API" with its own auth, its own schemas and its own risk profile, ServiceStack lets AI call the APIs you already have - as the signed-in user, through the same pipeline as every other client.

Because approval forms are generated from the same schema that powers API Explorer, users can inspect and correct what a model is about to submit before anything is written. And since it's your normal request pipeline, your authorization, validation, filters and business logic all still apply - a model cannot do anything the current user couldn't do themselves.

Host it your way

ServiceStack Services are decoupled from HTTP, from any UI technology and from any single host. The same implementation can serve a website, a mobile App, a queue consumer and a gRPC endpoint.

Why message-based APIs

ServiceStack's design follows Martin Fowler's Data Transfer Object pattern: when a call crosses a process boundary, send one well-defined message rather than many fine-grained calls.

This isn't stylistic. A remote call is the most expensive thing in general-purpose computing, and an interface that hides that cost behind method signatures encourages exactly the wrong shape of system.

RPC-style
  • A new method for every way a client wants to ask
  • Adding a parameter is a breaking change
  • N chatty round-trips where one would do
  • Can't be cached, queued, batched or deferred
  • Client-shaped APIs that outlive the client
Message-based
  • One coarse-grained message serves many use cases
  • Adding a field is additive and backwards-compatible
  • Any combination fulfilled in a single call
  • Cacheable, queueable, batchable, proxyable
  • Service-shaped APIs that outlive their consumers

Because the message is a plain POCO with no framework artifacts in it, the same type is your server contract, your client contract, your validation schema, your documentation, your UI definition and your AI tool definition. That's the entire trick - and it's why enabling a new capability so often costs one attribute instead of one project.

Read the long-form argument in Advantages of message-based Web Services and Why remote services use DTOs.

Everything in the box

What this means in practice

Less code to maintain

Admin screens, SDKs, docs and API clients are generated from the contract instead of hand-written and left to drift.

Fewer moving parts

Auth, jobs, caching, messaging, logging and analytics ship together and are designed to work together.

Genuinely testable

Services are dependency-free classes and typed clients make integration tests read like unit tests.

Fast by default

Built on high-performance serializers and data access, on the fastest APIs each .NET runtime offers.

Investment preserved

Libraries are continuously improved across 20+ years - not abandoned and replaced.

Commercially supported

Actively developed with paid support, and free for individuals & OSS.

Start in 60 seconds

INFO

Questions? Join the community on Discord, ask on GitHub Discussions or browse the Live Demos.