Wholesale price books. A signed API.
Approve a reseller, set their wholesale prices across five billing terms, hand them an HMAC-signed API key, and let them place orders against your catalog. One level, no sub-tenants, no surprises.
What the operator sees vs what the reseller sees.
Operators manage approvals, wholesale prices, and API access from the admin panel. Resellers get a dedicated set of pages inside the client panel for their orders, customers, products, and API settings.
The operator approves applications, sets per-product wholesale prices, toggles API access, and reviews API logs. Provisioning credentials stay master-only.
Approved resellers get a dedicated set of pages inside the client panel: Dashboard, Orders, Services, Products, Customers, API Settings, and the Program overview. Scoped to their own data only.
An approval workflow with three real states.
Status transitions are enforced by the reseller_profiles status column. They gate API access, order placement, and visibility into the catalog.
- 01.Pending
A user applies (or is invited) and a reseller_profiles row is created. The account exists but has no API access and cannot place reseller orders yet.
- 02.Active
An operator approves the application. approved_at and approved_by are recorded. The reseller can now place orders, generate an API key, and consume webhooks.
- 03.Suspended
A reversible halt. API requests are rejected and order placement is blocked, but existing services keep running so end clients are not impacted while you investigate.
Per product. Per reseller. Across every billing term.
Every product you mark as reseller-available is priced for every partner automatically: a tier price book per product, or the retail price minus the partner's discount. A row in reseller_products then overrides that for one product and one reseller, across every billing term you bill on, plus the setup fee.
A term that carries no price anywhere — not on the product, not in the tier book, not in the override — is rejected by the API. Nothing is ever priced at zero by accident.
- wholesale_monthly
- Wholesale price for the monthly billing term. The most common cycle for VPS, game, and shared hosting.
- wholesale_quarterly
- Three-month term. Often paired with a small wholesale discount versus the monthly rate.
- wholesale_semi_annual
- Six-month term. Useful when reseller margins are tight on shorter cycles.
- wholesale_annual
- Twelve-month term. Typically the deepest wholesale discount you offer.
- wholesale_hourly
- Hourly term for metered products. Falls back to the tier book or the discounted retail rate when left empty; a product with no hourly price at all cannot be ordered hourly.
- wholesale_setup_fee
- One-time wholesale setup fee charged when the reseller provisions the service.
- discount_rate_override
- Optional percent override for this specific product. Otherwise the partner gets the better of their tier discount and their own default_discount_rate.
- is_enabled / max_quantity
- Hide a product from a reseller without deleting the price row, or cap how many units one reseller can hold at once.
Signed partner integration with per-key rate limits.
Resellers integrate programmatically with HMAC-signed requests. Each request is authenticated by an issued key, rate-limited per reseller, and order placement validates an HMAC signature derived from the webhook secret on file.
Outbound events go the other way: webhook deliveries are queued, retried with backoff, and visible to the operator with status, attempts, and last-response detail. Integration details are shared on partner onboarding.
- place orders
- Place an order on behalf of an end client. Returns the order, the resulting service IDs, and the wholesale total.
- list priced products
- List every reseller-available product with the partner’s wholesale price for each billing term, in your base currency.
- list active services
- List active services the reseller owns, with status and renewal dates.
- list end customers
- List the reseller's end customers, optionally filtered by an external customer ID supplied at order time.
- auth · key + HMAC
- Scoped API keys per partner (read, orders, services, destructive, customers, account), each hashed at rest; every mutation carries an HMAC-SHA256 signature over the raw body and a timestamp, keyed on the partner’s signing secret.
- rate limit · per partner
- Requests-per-window cap stored per reseller. Defaults to 1000 and is adjustable per partner.
- webhooks · queued + retried
- Outbound events are queued with status, attempts, next-retry, and last-response code so failed deliveries are inspectable from the admin UI.
- audit log
- Every partner request is logged per reseller for usage analytics and dispute resolution.
What the reseller program is — and isn’t.
The reseller surface is intentionally narrow. We list both what it does and what it doesn’t, so there are no surprises in procurement.
One operator, many resellers, end clients beneath them. The schema does not model nested resellers and the platform does not pretend to.
Five billing terms plus setup fee, per product, per reseller. The price book is the contract.
HMAC-signed order endpoints, per-key rate limit, queued and retried outbound webhooks with full delivery state.
Custom domains and SSL operate at the tenant pod level only, not per reseller. Themes are tenant-global. If you need per-reseller branding, run a separate tenant for them.
Try it on your own data. Refund inside 14 days if it’s not the fit.
Pick a tier and provision a tenant in under two minutes — isolated K3s namespace, your own database, the full product. If FluxBilling isn’t the right fit inside 14 days, open a ticket and we’ll refund the subscription. No sales call, no qualification gate.
- 01.< 1 minPick a tierLite from €4.95/mo. Upgrade later, no migration.
- 02.< 2 minProvision the tenantIsolated K3s namespace + your own PostgreSQL database. Full product, your data.
- 03.d0 — d14Refund inside 14 daysNot the fit? Open a ticket within 14 days and we refund the subscription. No questions, no qualification gate.