What is SnugNut

SnugNut is a catalog of the missing internet primitives - the capabilities software needs in order to participate in the world rather than just describe it. Somewhere to keep state. A queue to wait in. A ledger to settle against. A way to prove who you are, rank something, hold a reservation, or remember what happened last time.

There are 69 of them, and each one is a call away.

Soft infrastructure

Every service here is shaped like a system you already understand. A queue behaves like a queue. A ledger balances. A rate limiter hands back the budget it is holding you to. Nothing about the model is novel, and that is deliberate - you should be able to guess how a service works before you read its page.

What is missing is the friction. There is no project to create before you begin, no roles to attach, no console to learn, no capacity to plan, and no separate account per capability. The shape of infrastructure, without the apparatus that usually comes with it.

Built for a new kind of caller

Most platforms assume a person will read the documentation, install a library, create an account, and wire things together over an afternoon. That assumption is getting shakier. Increasingly the thing reaching for a capability is an agent: it reads a schema, makes a call, and moves on. It will not sit through onboarding, and it will not install anything.

So every service here is designed to be usable on first sight. The surface is plain HTTP with JSON. Each service publishes its own OpenAPI description, which is what the API reference is generated from - the same description an agent can read to work out how to call it. Nothing needs to be generated, vendored, or kept in sync on the caller's side.

That design is just as good for the people building those agents, which is the point. What makes a capability easy for a model to invoke - predictable shapes, honest errors, no hidden setup - is what makes it pleasant for a person too.

What you get

The catalog covers the ground most products need: storage and state, messaging and realtime, background work, virtual economies, identity and trust, game mechanics, simulation, and the small pieces around a product like onboarding tours, forms, and waiting rooms. The service catalog lists all of them.

Every service shares the same conventions, so learning one teaches you the rest:

• The same response shape. Success and failure arrive in one envelope with a machine-readable error code. See Responses and errors.
• The same way to ask for less. Filtering, sorting, and pagination use one grammar across every list endpoint. See Search queries.
• The same credentials. Tokens and scoped API keys, with organizations, SSO, and directory provisioning when a company needs them. See Authentication.
• The same limits. Every response carries its rate-limit budget in headers you can read before you get refused. See Rate limits.
• A command line that matches. The snug command mirrors the API service for service, with JSON output meant for scripts and agents. See the CLI.

Where to go next

The Quickstart takes you from nothing to your first authenticated call. The service catalog is the map. The API reference is every endpoint, callable from the page.