Create your store

Request a store

Post your email, store name, and desired slug to the public signup route. It is rate-limited (per IP and per email) and returns the same 202 whether the slug is new or a repeat, so it never leaks which slugs exist.

curl -X POST https://api.ruo.pro/v1/signup \
  -H "Content-Type: application/json" \
  -d '{
    "email": "owner@example.com",
    "store_name": "Nova Peptide",
    "desired_slug": "nova-peptide"
  }'

A 202 returns { "status": "requested" }. A slug already backed by a real store or an in-flight run is a 409 slug_taken. You can also pass an optional theme (a featured starter theme key); an unknown value is a 400, never silently defaulted.

Verify your email

The signup email carries a single-use, TTL’d token. Completing verification provisions the draft store and creates your owner identity, reusing the same provisioning code path an operator run uses.

curl -X POST https://api.ruo.pro/v1/signup/verify \
  -H "Content-Type: application/json" \
  -d '{ "token": "the-token-from-your-email" }'

A 201 returns a run summary: { "run": { "id", "slug", "status", "goLiveStage" } }. The store now exists in draft. Note what this response does not contain — no API key. A self-serve run defers key issuance to your own one-time self-mint, so a secret can never leak in this body.

Mint your first key

You are now a verified owner with an identity session. Mint your first fdk_ merchant credential against the draft store. Send your identity session as the bearer — this is the one route that takes a session rather than an fdk_ key.

curl -X POST https://api.ruo.pro/v1/my/credentials/initial \
  -H "Authorization: Bearer <your identity session>"

A 201 returns { "credential": { "id", "key", "scopes" } }. The plaintext key appears once — store it now. Because the store is still draft, the key carries the pre-live build scope set only: read:own_store, write:own_store, read:own_catalog, manage:own_catalog, manage:own_media, and manage:own_domains. That is everything you need to design and stock the store, and deliberately nothing that touches shoppers or money. After go-live, re-mint through the same route to get the full scope set.

Read your store back

Confirm the key works and inspect your store’s current state.

curl https://api.ruo.pro/v1/my/store \
  -H "Authorization: Bearer fdk_your_key_here"

import { createFlightdeckClient } from "@dscodotco/sdk";
 
const client = createFlightdeckClient({
  baseUrl: "https://api.ruo.pro",
  fdkToken: process.env.FDK_TOKEN, // server-side only
});
 
const { store } = await client.request("get", "/v1/my/store");
// store.status is "draft" until the operator takes you live

The response carries tenantRef, storeNumber, displayName, supportEmail, status, and managementMode, plus the scopes your key holds.

Set your store details

Update the display name and support email (requires write:own_store). Omit a field to leave it unchanged; pass support_email: null to clear it.

curl -X PATCH https://api.ruo.pro/v1/my/store \
  -H "Authorization: Bearer fdk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{ "display_name": "Nova Peptide", "support_email": "help@example.com" }'

Build, then hand off for go-live

With the build key you can now add products (Add products), publish a site manifest (Hosted storefront), and attach a domain (Custom domains) — all against the draft store, all invisible to shoppers.

When you are ready, the platform operator runs the go-live ladder that promotes status to live. Once live, re-mint your key at POST /v1/my/credentials/initial to receive the full scope set (orders, fulfillment, marketing, money surfaces, and the rest).