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.
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.
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.
A complete multi-provider AI App at /chat using your App's existing users, database and security boundary.
Expose the same approved APIs to external AI Assistants over the Model Context Protocol.
Design documents with AI, publish immutable revisions, then render production PDFs with no LLM at runtime.
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.
- 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
- 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​
Admin screens, SDKs, docs and API clients are generated from the contract instead of hand-written and left to drift.
Auth, jobs, caching, messaging, logging and analytics ship together and are designed to work together.
Services are dependency-free classes and typed clients make integration tests read like unit tests.
Built on high-performance serializers and data access, on the fastest APIs each .NET runtime offers.
Libraries are continuously improved across 20+ years - not abandoned and replaced.
Actively developed with paid support, and free for individuals & OSS.
Start in 60 seconds​
Pick a template and download a ready-to-run App - Blazor, Vue, React, MVC, API-only and more.
A guided walkthrough from empty project to a working, documented, typed API.
15 typed languages, AI Chat, API Tools, API Schemas and PDF Studio in the latest release.
INFO
Questions? Join the community on Discord, ask on GitHub Discussions or browse the Live Demos.