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 four 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.
- 04.Terminated
The end of the relationship. The profile remains in the database for audit, but the reseller can no longer authenticate, place orders, or receive webhook deliveries.
Per product. Per reseller. Across every billing term.
Each row in reseller_products binds one product to one reseller and stores the wholesale price for every billing term you bill on, plus the setup fee. Resellers see only the products you have priced for them.
If you do not need a term, leave it null and the API rejects orders on that cycle. No surprise pricing fall-throughs.
- 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 or bare-metal-style products. Leave null if the product does not bill hourly.
- wholesale_setup_fee
- One-time wholesale setup fee charged when the reseller provisions the service.
- discount_rate_override
- Optional percent override that replaces the reseller’s default_discount_rate for this specific product.
- 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 the products the reseller is priced on, with the wholesale price for every billing term you have populated.
- 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
- Each profile carries a hashed key and a key prefix; order placement validates an HMAC signature derived from the webhook secret on file.
- 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.