One API.
15 languages.
Define your contract once. Every developer gets clean native DTOs, an idiomatic feature-rich Service Client, editor completion and compile-time confidence — generated from a running API, not hand-written and left to drift.
$ npx get-dtos go https://example.org
Saved to: dtos.go
$ npx get-dtos swift https://example.org
Saved to: dtos.swift
The contract is the product
Stop rebuilding the same API for every platform.
Your ServiceStack Request DTO already knows its response type, route, HTTP method, validation and API metadata. Add ServiceStack Reference carries that intelligence into every client.
The result feels hand-built in every language: native naming and types, discoverable contracts, structured errors, authentication, AutoQuery, uploads, batch and one-way requests.
There are no hand-written URLs, no anonymous JSON objects and no duplicated response models — the generated file is the contract, and refreshing it is how you find out what changed.
Native by design
Idiomatic DTOs and clients that belong in each ecosystem.
Types end to end
Completion while you build. Compiler feedback when contracts change.
Always in sync
Refresh one generated file whenever the API evolves.
Production capable
Auth, rich errors, queries and uploads without boilerplate.
A lighter approach
Add a reference, not another SDK project.
Traditional SDK development multiplies work: every API change has to be reflected in docs, models and client code for each platform. Generated SDKs reduce that, but often bring large toolchains, verbose output and clients that feel foreign in the language using them.
- ✕A separate SDK repo and release train per platform
- ✕A spec file kept in sync by hand
- ✕Heavyweight codegen toolchains in every build
- ✕Generated clients that feel foreign in their language
- ✕Server changes surfacing as runtime failures
- ✓One command against a running API
- ✓A single generated source file per client
- ✓Nothing to install or configure on the server
- ✓Native naming, types and error handling
- ✓Breaking changes caught by the language's own tools
Define a typed Request DTO
Implement it once on the server
Refresh the reference in any client
Call the API with native types
No schema translation layer. No parallel SDK release train. No drift between a wiki and the API that's actually deployed.
Two commands. Done.
From running API to native types in under a minute.
Pick your language. Install its client. Generate the complete API contract directly into your project.
Nothing needs to be installed or configured on the server — every ServiceStack App already publishes the
metadata get-dtos reads. Run
npx get-dtos with no arguments to
list every supported language.
From websites to systems software
Every language your organization builds with.
A mobile team and a systems team don't need to agree on one programming language to share the same precise API contract.
.NET
First-class typed clients for the .NET languages
Web & Scripting
Websites, automations and internal systems
Mobile
Native apps on every major mobile platform
Cloud & Systems
Cloud services, tooling and native binaries
Also available: ES3 CommonJS for legacy JavaScript environments.
A real contract, everywhere
The world's most important API, in every language.
ChatCompletion is not a trivial request — nested messages,
polymorphic content, model settings and a rich response graph. Choose a language to see that entire
contract as native code.
A better API architecture
One API. 15 Languages. Zero Hand-Written SDKs.
Define your contract once. Every developer gets clean native DTOs, an idiomatic feature-rich Service Client, editor autocomplete, and compile-time confidence - generated directly from a running API, not hand-written and left to drift.
More than data classes
One consistent capability set, expressed natively.
The clients don't force one language's style everywhere. Go returns values and errors. Rust supports async results and optional blocking calls. Ruby uses natural constructors and exceptions. Zig makes allocation and cleanup visible. What stays consistent is what the integration can do.
Typed request & response DTOs
Generated from the live ServiceStack API, with descriptions and validation metadata travelling with the types.
Response & method inference
The Request DTO knows which response it returns and how it should be sent - no hand-written URLs.
Structured errors
ResponseStatus and field-level validation failures in a common shape across every language.
Authentication
Basic Auth, API Keys, Bearer tokens, JWTs, refresh tokens and session cookies.
Typed AutoQuery
Query rich data APIs without hand-building filter, paging or sorting plumbing.
Batch & one-way APIs
Efficient multi-request workflows and fire-and-forget messaging patterns.
Multipart & file uploads
For APIs that go beyond JSON-only requests, including multi-file uploads.
Custom routes & URLs
Drop to direct HTTP control whenever an integration needs it.
This balance is what makes a generated integration feel like a real client library instead of a dump of data classes. ServiceStack standardizes the behavior and contract whilst each implementation stays idiomatic to its ecosystem.
However you work
Generate from the terminal, your IDE, or a URL.
npx get-dtos
No .NET install and no global tool required. Works the same in any environment, CI included.
# generate
npx get-dtos python https://example.org
# refresh in place
npx get-dtos python
# list every language
npx get-dtosIDE integration
Add and update a reference without leaving your editor.
- ›Visual Studio & Rider
- ›IntelliJ IDEA & Android Studio
- ›VS Code & Xcode
- ›Any editor, via the CLI
Straight from the API
Every ServiceStack App serves its own DTOs. Open the URL in a browser and read them.
GET /types/typescript
GET /types/python
GET /types/swift
GET /types/goCustomize what's generated
Generated files begin with the options used to produce them. Uncomment a line, re-run the command and the output changes — per client, without touching the server.
/* Options:
Date: 2026-08-13
Version: 10.1
BaseUrl: https://example.org
//GlobalNamespace: dtos
//AddServiceStackTypes: True
//IncludeTypes: Booking,QueryBookings
//ExcludeTypes: Authenticate
//AddDescriptionAsComments: True
*/Beyond developer convenience
Typed APIs are an architectural advantage.
An API contract is a boundary between teams, applications and release schedules. If that boundary is represented by copied JSON examples, every consumer has to interpret and maintain it independently — and small server changes become latent runtime failures spread across a fleet of clients.
The deployed API publishes the contract
Consumers refresh it on demand and let their existing language tools identify affected code.
Behavior lives in the client
Authentication, transport and error handling are reusable, not reimplemented by every team.
Polyglot without fragmentation
Each team uses the platform best suited to its product whilst the backend stays consistent.
Combinations this makes practical
- ✓A TypeScript web App and Swift/Kotlin mobile Apps sharing one backend
- ✓Go workers and CLI tools automating operational APIs
- ✓Rust desktop software consuming authenticated business services
- ✓Ruby and Python systems integrating with the same platform
- ✓Zig utilities calling the same APIs from a minimal native binary
- ✓AI features exposed once and used from all of them
Build once. Reach everyone.
Your API should speak your developer's language.
Your APIs are already typed. Now virtually every application your organization wants to build can be typed end to end as well.
$ npx get-dtos go https://example.org