Your users publish.
You run nothing.

A finished publishing product behind your brand and your billing: spaces, immutable versions, instant rollback, custom domains with automatic SSL. You call one API. Your customer sees you, full stop.

One POST per customer site

Publishing on a customer’s behalf is a single POST with a file or zip. The receipt is JSON: a live URL and a permanent version URL. Store it against your own record and move on. No SDK to adopt.

Publish on behalf of a customer, then read the receipt:

$ curl -F archive=@site.zip \
    -H "Authorization: Bearer $TENANT_KEY" \
    -H "X-Spacefast-On-Behalf-Of: cust_4812" \
    https://api.spacefast.com/v1/publish
{ "live_url": "…", "version_url": "…", "version": "v3" }

Map your data model onto three nouns once; the rest is API calls.

Tenant

Your platform

Keys, billing, quotas and rate limits live here, scoped to you alone. Tenant keys authenticate server-side. Your users never see a Spacefast credential, and you never store per-user secrets.

Site

One per customer

Every request names who you are acting for with X-Spacefast-On-Behalf-Of: cust_4812, and the audit trail records it. A support question is a lookup, not an investigation.

Space

Files in, live URL out

Each space carries immutable versions, rollback, routing, scoped access and domains.

Spacefast is in research preview. Put your name down below and we’ll come and find you.

The API we use, not a partner edition

There is no separate partner stack. The consumer product at spacefast.com is tenant #1 of the same control plane: our dashboard, CLI and agents call the endpoints you call. That keeps the API honest. A feature isn’t done until it works through the API, so partners get it the day it ships.

Per-tenant isolation

Scoping, quotas and rate limits are per tenant, so another integration's busy day is never your incident.

An audit trail on every request

Each call records the acting key and the customer it acted for.

Idempotent provisioning

Idempotency-Key is honored per tenant, so a retried request can’t double-provision a customer.

Typed errors

A stable { error } envelope with machine-readable codes. Your integration branches on codes, not strings.

Boring infrastructure

The same infrastructure that serves WordPress.com. Automattic has kept other people's websites online for more than twenty years.

Everything your customers expect, without building it

Each of these is shipped in the product underneath and surfaced in yours.

An undo

Every publish for every customer is frozen as an immutable version, and the live URL flips atomically. Rolling a customer back promotes an earlier version: a pointer flip, live in seconds. “Restore from backup” becomes one API call.

Their own domain

Point any domain a customer owns at their space with the DNS values the API returns. Certificates are issued and renewed automatically at any number of domains. Live diagnostics report when each one resolves, status you can show in your own UI.

Routing that ships inside the upload

Each space carries its own _redirects and _headers, a Netlify-compatible subset compiled once at publish. Redirects, SPA fallbacks, proxied paths, cache headers: you run no per-tenant config service, and it all rolls back with the version.

Agents that already know the way in

The API ships with llms.txt, an agent-card and a hosted MCP server with typed tools. If your customers build with Claude, Codex or ChatGPT, publishing to your platform is one message.

A clean exit to pass on

One command downloads every file of any version straight to a folder, ready to serve anywhere.

Platform access is by conversation. We onboard partners individually, with limits, pricing and domains sized to what you’re building. Tell us what you’re making.

Talk to us

Or start in the Platform API docs.