Developer docs.

1. npx create-cumulus@latest my-app
2. Choose the hosted Relay agent-auth mode.
3. Register the product at /dev/products.
4. Copy the webhook secret into RELAY_WEBHOOK_SECRET.
5. Fill in onSignup. Return { accountId, apiKey } or { accountId, credentials }.
6. relay scan <slug> verifies reachability + signature enforcement.

The canonical category vocabulary is database, hosting, email, newsletter, auth, storage, analytics, payments, cms, observability, ai, search, saas. During the validation sprint, ai and database are featured in the public /v1/index overview; registration still accepts the full vocabulary. Supply these when you register:

POST /v1/dev/products
{
  slug: 'my-product',
  display_name: 'My Product',
  signup_webhook_url: 'https://...',

  // Discoverability
  description: 'One-line of what you do.',
  docs_url: 'https://...',
  homepage: 'https://...',
  npm_package: '@me/sdk',
  categories: ['database'],          // canonical; aliases auto-resolved
  capabilities: ['postgres', 'serverless'],
  pricing_model: 'free-tier',        // free | free-tier | paid | usage-based | freemium
  pricing_url: 'https://.../pricing',
  free_tier_summary: '500MB storage forever.',
}

Aliases like hoster → hosting are resolved server-side. Unknown categories fail with invalid_categories and the full canonical list so your registration script can retry. The same fields are accepted by the MCP register_tenant_product tool.

Every call carries X-Relay-Signature: sha256=<hex> (HMAC of the raw body using your secret) and X-Relay-Provider: <slug>.

// kind === 'signup'
{
  kind: 'signup',
  signupId: '<uuid>',
  email: 'user@example.com',
  input: { /* whatever the agent passed */ },
  provider_slug: 'your-slug',
}
// response
{
  accountId: '<your internal id>',
  apiKey: 'plaintext_key',
  externalId?: '<stable id>',
}

// structured handoff response, for providers with multiple credentials
{
  accountId: '<your internal id>',
  credentials: {
    endpoint: 'https://...',
    database_id: 'db_...',
    data_token: '...',
    admin_token: '...'
  },
  externalId?: '<stable id>',
}

// kind === 'create_api_key'
{ kind: 'create_api_key', account_id: '<id>', label: 'key-...' }
// response
{ key: 'plaintext_key', providerKeyId?: '<id>' }

// kind === 'revoke_api_key'
{ kind: 'revoke_api_key', account_id: '<id>', key_id: '<id>' }

// kind === 'teardown'
{ kind: 'teardown', account_id: '<id>' }

Relay does not persist third-party API keys. Your webhook returns the plaintext once; Relay hands it straight back to the calling agent and only retains a bookkeeping row (alias + your providerKeyId) so future revocations have a handle.

relay products — list tenant products + this-week counters
relay products rotate <slug> — rotate webhook secret
relay stats — weekly status rollup
relay users — end-users who signed up
relay logs — recent signup_jobs
relay scan <slug> — reachability + signature check

Per-token fixed-window best-effort limits apply to /v1/*writes (~60/min) and reads (~300/min). The ceiling is per serverless instance rather than globally synchronized — true traffic can burst N × the limit across N warm instances. It's a safety net against runaway loops, not a hard global quota.

One offer: $2,500 prepaid for a 30-day founding partner sprint. Renewal at $2,500/month, month-to-month, decided after the day-30 cohort report. End-users pay nothing. There are no per-action meters, tiers, or credit packs surfaced during this phase — those mechanics exist in the codebase but are dormant while we're still proving the channel with a small handful of integrators.

Operational guardrails are still in place to protect both sides: a per-end-user signup soft cap (50/month), a per-end-user action soft cap (200/month), and the per-instance rate limits on the Relay API itself (60 writes/min, 300 reads/min). Read-only operations (list accounts, fetch status, browse the catalog) are never billed. None of these are sales surfaces — they exist purely to keep a runaway agent from causing damage.

Use Relay when you want AI agents to be able to onboard your end-users into your product without you building the agent-side wiring yourself. You keep your own auth (Supabase, Clerk, your own session table — anything) and your own user records; Relay only vouches for identity and brokers the agent-callable signup endpoint your existing webhook handles. Pricing is fully integrator-paid: end-users see no card, no meter, no upgrade prompt. Your only ongoing cost is the monthly action quota you choose at /pricing. The fairness debounce means you can plan capacity from total monthly onboardings + key-lifecycle days, not from raw call volume — much easier to forecast.

Neon does not expose a way to revoke a single connection URI. When you call revokeon a Neon key, Relay updates its own state but cannot invalidate the connection string at the provider — to truly revoke access, reset the project's database password through the Neon Console or the Neon Management API. Other providers (Vercel, Resend, tenant-defined products) revoke server-side as expected.

When you no longer need a developer workspace you can delete it from /dev/settings → Danger zone. Only the workspace owner sees the option. You'll be asked to type the workspace name to confirm — once submitted, the deletion is immediate and cannot be undone.

Deleting a workspace permanently removes every team member, registered product, feature flag, integrator key, and subscription history tied to it. End-user account rows and signup history are kept, but they lose their link to this workspace.

If you have a live subscription, cancel it first at /dev/billing. Relay blocks deletion while Stripe considers the workspace trialing, active, or past_due to protect against accidental loss of billing state.