If you're building a product on NOWAITN — a waitlist app, an ordering product, a booking tool — your clients are yours. The model is tenants minting tenants: your account is a reseller tenant, and each of your clients becomes a sub-tenant — a tenant of your tenant — that you operate entirely through your own API key. Your client never receives a NOWAITN login, never sees a NOWAITN screen, and never holds a NOWAITN credential.
The model
A sub-tenant is a complete platform organization: its own product catalog, its own ordering page slug, its own branding, its own event stream, its own usage metering. What makes it "sub" is policy, not plumbing — it's owned by your tenant, billed to you, and every org-scoped API accepts its organization id under your key (one hop down; never up, never between your clients). Don't create organizations any other way: POST /v1/tenants/onboard is reserved for NOWAITN provisioning and will point you back here.
Getting enabled
Reseller status is enabled per account by NOWAITN — talk to us. Once enabled, your existing API key gains the sub-tenant endpoints and MCP tools.
Minting a client (sub-tenant)
POST /v1/orgs/{yourOrgId}/sub-tenants with a name, an optional slug (this becomes their public ordering page at 0rder.app/{slug} if you enable Orders), and the apps to enable — any subset of the apps your own organization has. The response includes the client's organization_id: use it in any org-scoped path exactly as you use your own. MCP: mint_sub_tenant, list_sub_tenants, update_sub_tenant.
Operating on behalf of a client
Everything you can do for your own organization, you can do for a client by swapping the organization id in the path: seed their catalog (POST /v1/products with their organization_id), take and manage their orders (/v1/orders/{clientOrgId}/…), fetch their storefront link, subscribe to their events. Usage and features are scoped and tracked per client automatically, because everything on the platform is organization-scoped.
Keeping your brand in front
The hosted pages (ordering at 0rder.app, tracking at my0rder.com) are optional defaults, not requirements. Pass your own tracking_url when creating orders and customer notifications link to your status pages; pull the same order state from the API (status, paid state, balance, items) and render it on your own domain. Rate limits are per API key — see the X-RateLimit-* headers on every response.
Feature flexibility per client
Each sub-tenant's enabled_apps is independent — one client might use Orders and Products, another adds Queue and Reservations. Change the mix any time with PATCH /v1/orgs/{yourOrgId}/sub-tenants/{clientOrgId}; features gate immediately platform-wide, and usage is metered per sub-tenant.