Stainless

Introducing Stainless: The API Company

Stainless offers quality fittings for your REST API.

You can think of us like Stripe's API platform as a service, but our ambitions are a little bigger1, and our starting point is a little narrower.

Our first product is well-typed client libraries as a service. In the era of ubiquitous static typing, it's ridiculous that inter-service interfaces (and especially inter-company interfaces) go completely untyped, without autocomplete and docs right in your editor. But the open-source generators for OpenAPI just aren't very good; nobody uses them for their official SDKs.

Our founder2 built Stripe's codegen system and TypeScript definitions, and is applying the same concepts for any API at Stainless3: just send us your OpenAPI spec and we generate code and publish it to npm/pypi/etc.4 for you every time your API changes.

All well and good — until you forget to update your OpenAPI spec when you change the behavior of your API. Most people maintain their spec in some forlorn yaml file — no wonder nobody's docs are up to date.

That's why our second product will be an open-source API framework for TypeScript.

At Stripe, we had this great Ruby DSL where you'd declare everything about your API in one place — for each param/field, the type, documentation, validation, authorization, serialization/deserialization, etc. all lived right there next to the actual behavior. That's what powered our mostly-accurate API docs, mostly-consistent API, and ultimately our typed clients.

Weirdly, nothing like that exists in Node — or most languages for that matter (though Python's FastAPI looks great). You want to use OpenAPI so TypeScript can guide your backend & frontend development with the smoothness of the Prisma ORM? Good luck with duct tape and baling wire.

That's why our open-source API framework will let you easily declare your API's docs and types right alongside your behavior, coupled with a frontend client library that gives every endpoint in your backend a name, types, and even a normalized cache. It's the missing link between Prisma and Next in the golden stack of the future.

Ultimately, it's our mission to bring ~all the advantages of GraphQL and gRPC5 to the simplicity and ubiquity of REST.

If you think this might be fun to work on, reach out6 or check out our JD if you're into that kind of thing.