Resellers and MSPs

Three separate records

Sectigo partner management keeps three effective-dated records for a channel relationship. None implies another, and ending one never changes the others.

Delegated administration

1. The reseller signs up and creates its organization like any customer. Partner management registers it as a reseller.
2. Partner management proposes a delegation to a customer tenant: the roles (trust administrator, service owner, partner administrator, billing administrator or auditor; never owner) and the effective dates. A proposal grants nothing and is visible only to the customer.
3. An owner of the customer accepts it under Organization, Partner delegations (POST /v1/delegations/{id}/accept, fresh sign-in), or declines it.
4. While it is in effect, reseller owners hold every delegated role in the customer tenant; other reseller members hold the delegated roles they also hold in the reseller organization.
5. An owner of either side ends it at any time (POST /v1/delegations/{id}/revoke); access stops on the next request. It also stops when the end date passes or when the reseller registration ends.

Delegated roles work only in signed-in browser sessions. They never become API credentials, never grant support access or audit export rights, and never manage members. Every action a reseller member takes is in the customer's audit log under their own identity; acceptance and revocation are recorded on both organizations' logs.

The reseller console

From the reseller organization's page, Open the reseller console lists the customer tenants currently delegated to you (GET /v1/organizations/{id}/delegated-tenants) with your roles in each. Work in this tenant switches the portal to that customer's context; the organization switcher on every page moves between your own organization and your delegated tenants.

Tenant separation

A delegated reseller cannot discover unrelated tenants. Every list, search, total and export is scoped by the same memberships, so the reseller sees only its own organization and the tenants delegated to it now: not proposals that were never accepted, not tenants it only pays for or referred, and not other customers of the same tenant. Requests for anything else answer 404. The test suite proves this by calling every GET endpoint of the API as a reseller and checking each response for other tenants' identifiers and names.

Reseller payer

For a reseller that buys capacity and bills its own customer, partner management makes the reseller's billing account the payer for the customer tenant from a date; the previous payer ends on that date and its history is kept. Paying for a tenant grants no tenant-admin rights. The customer's production entitlement still comes from its own subscription or approved invoice terms.

Referral attribution and commission

For a referral, partner management attributes the customer to the referrer from a date with a commission rate in basis points. Commission accrues on the customer's finalized invoices (pre-tax subtotal, rounded down to a whole minor unit) and is exported for Finance. There are no payouts until a payout model is approved.

Allocations on the bill

Each finalized reseller invoice is allocated across the customer tenants the reseller paid for during its service period, in proportion to each tenant's entitled production connections (equally when none are entitled). The allocations of one invoice add up to its pre-tax subtotal exactly; tax stays with the reseller. Finance sees allocations and accruals by period, in original currencies that are never summed together, and exports a hashed, recorded file.