Management API

Everything the CLI and portal UI do goes through the portal's own HTTP API — there is no private back channel. Anything you can click, you can script.

This page is for your own tooling. If the caller is an AI client, use the MCP endpoint instead: it's these same operations exposed as MCP tools — with argument schemas, a project-scoped token you can rotate, and the docs served alongside them — rather than endpoints a model has to guess its way around.

Provision a project per customer

A B2B product that gives every tenant an isolated database: create the project, publish its schema, and read back the keys, all from your signup flow, instead of clicking through the portal for each new account.

Ephemeral environments in CI

Spin up a throwaway project for a pull request, run the test suite against a real database and real functions rather than mocks, and delete it when the branch merges. (For most CI, snoozestack dev against the checkout is even simpler — no hosted project needed at all.)

Infrastructure as code

Keep secrets, scheduled functions, and DNS records in a script under version control, so a rebuilt project is identical to the one it replaced.

Internal admin tooling

Build your own support console — look up a user, ban an account, re-run a schedule — without giving support staff portal logins.

Authenticating#

Sign the CLI in once — snoozestack user login opens your browser, and works for an account that signs in with Google as well as one with a password — then snoozestack user token prints the bearer token it stored in ~/.snoozestack/config.json. Treat it like a root credential: it can read every key and delete every project in the organization.

snoozestack user login          # approve the code in the browser tab it opens
TOKEN=$(snoozestack user token)
 
curl -s https://snoozestack.com/api/projects -H "Authorization: Bearer $TOKEN"

A machine with no browser and no CLI can exchange an email and password for the same token at /api/auth/cli-token (POST {"email", "password"}) — for a password account only. For anything unattended, prefer a project token (snoozestack projects tokens create): it is scoped to one project and revocable from anywhere.

A worked example — provision a project, wait for it, apply a schema, and print the keys an app would need:

set -euo pipefail
API=https://snoozestack.com/api
AUTH="Authorization: Bearer $TOKEN"
 
# 1. Create the project — the response is the project row, incl. its keys.
REF=$(curl -s -X POST "$API/projects" \
  -H "$AUTH" -H 'Content-Type: application/json' \
  -d '{"name": "tenant-acme"}' | jq -r .slug)
 
# 2. Wait for the project's runtime to come up: runtime/state is 404 until
#    the starter publish that creation kicks off has a container answering.
until curl -sf "$API/projects/$REF/runtime/state" -H "$AUTH" >/dev/null
do sleep 3; done
 
# 3. Apply the schema: the schema.json that "snoozestack schema build" writes
#    from schema.mjs, published as the project's new schema version.
curl -s -X POST "$API/projects/$REF/schema" \
  -H "$AUTH" -H 'Content-Type: application/json' \
  -d "{"schemaJson": $(jq -Rs . < snoozestack/schema.json)}"
 
# 4. Hand the app its credentials. There is no "url" field — a project is
#    always served at https://<slug>.snzzz.com.
ANON=$(curl -s "$API/projects/$REF" -H "$AUTH" | jq -r .anon_key)
echo "SNOOZESTACK_URL=https://$REF.snzzz.com/api"
echo "SNOOZESTACK_ANON_KEY=$ANON"

Projects & schema#

Functions, schedules & secrets#

Auth#

Storage & queues#

Web & domains#

Monitoring#

Organization#

Responses are JSON; failures carry a non-2xx status and an { "error": "…" } body. See the CLI reference for the commands that wrap the most common of these calls.