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.
What we review before enabling reseller mode
Reseller access isn't a self-service toggle — it's a permission tier that unlocks the ability to create, bill, and manage other organizations inside the platform, so we run a short verification step first. When you reach out, be ready to share:
- Business context: whether you're a managed service provider, franchise operator, agency, or software vendor embedding NOWAITN under your own brand.
- Expected client volume: a rough estimate of how many sub-tenants you plan to mint in the first 90 days and over the following year. This helps us right-size your rate limits and provisioning quotas.
- Billing arrangement: whether you'll be invoiced in bulk and re-billing clients yourself, or whether each client organization will be billed directly with you as the admin of record.
- Primary contact and backup contact: at least two team members who can be reached for account-level changes, since reseller actions can affect many downstream organizations at once.
Most reseller requests are reviewed within one to two business days. Larger deployments — for example, a franchise network migrating hundreds of locations at once — may involve a short onboarding call to map out naming conventions, default feature sets, and data isolation requirements before the first sub-tenant is created.
What changes on your account once enabled
Enabling reseller status doesn't replace your existing account — it extends it. Your current organization becomes the parent or master account, and everything you've already configured (users, integrations, billing details) stays intact. On top of that baseline, you gain:
- Access to the sub-tenant creation endpoints and corresponding MCP tools for programmatic provisioning.
- A reseller dashboard view that lists every client organization you manage, with quick links to switch context into each one.
- The ability to define default templates — service menus, booking rules, notification settings — that get applied automatically whenever you mint a new client.
- Expanded API key scopes, so the same credentials you already use for your own operations can now target client organizations without issuing separate keys per client.
API key and permission considerations
Because your existing API key inherits reseller-level scopes, it's worth reviewing how that key is stored and who on your team has access to it before you flip the switch. We recommend:
- Rotating the key immediately after reseller status is enabled, especially if it has been shared across multiple tools or team members previously.
- Using scoped, role-based internal access so junior staff can operate within specific client organizations without holding the master key that can create or delete tenants.
- Enabling audit logging on reseller-level actions (tenant creation, deletion, and configuration changes) so you have a clear trail if multiple team members are provisioning clients.
Preparing your team before you mint your first client
Before creating your first sub-tenant, it's worth deciding internally how you'll name organizations (a consistent convention like client-slug or account number pays off at scale), which features will be on by default, and who on your team is authorized to onboard new clients. Teams that document this upfront typically move from "enabled" to their first ten live client organizations within a week, versus several weeks of ad hoc trial and error.
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.