# Reseller model

The reseller model is the account and billing structure used by Reseller Partners. It uses a two-level account structure: the partner holds one Signable partner account, and each of the partner’s customers has a sub-account beneath it.

This guide covers the account architecture, available API endpoints, and division of responsibilities between the partner and Signable.

Two-level reseller account structure.
## Account structure

- A partner account supports an unlimited number of sub-accounts.
- Each sub-account represents one customer and can have its own branding for signature-request emails and signing pages.
- Day-to-day operations are carried out through the API. As an exception, partners can set up templates manually in the Signable web app.
- Envelope usage is aggregated across all sub-accounts and invoiced to the partner at the end of each billing period.


### Sub-account structure

- Each sub-account can have only one associated user and email address.
- Sub-account customers cannot access the Signable web app. Where web-app configuration is required, such as manual template setup, the partner completes it through the partner account.


### Reseller partner compared with direct customer

| Aspect | Reseller model | Direct account |
|  --- | --- | --- |
| Interface | API only; no web app login for day-to-day operation | Signable web app |
| Branding | Partner or sub-account branding (white label) | Signable or customer branding |
| Support | Partner supports their customers | Signable supports the customer |
| Billing | Monthly, in arrears, for aggregate sub-account usage; Direct Debit or card | Standard pricing plans, in advance |
| Templates | Set up in the web app by the partner | Managed by the customer in the web app |


## Signable API

You will use your partner account API key to access the partner endpoints. You will use sub-account API keys to interact with all other endpoints. See [Authentication for resellers](/partners/reseller-authentication) for more information.

Signature events are delivered to your platform using [webhooks](/webhooks).

To embed the signing experience in your product’s user interface, see [Embedded signing](/guides/embedded-signing/embedded).

For error responses specific to these endpoints, see [Partner error codes](/errors/partners-errors).

Signable's role is limited to explaining how the API behaves during the build and in operation. See [Integration build and testing](/partners/getting-started#2-integration-build-and-testing)
).

## Billing

Reseller pricing depends on volume and use case. For more information, [contact the Sales team](https://www.signable.com/signable-partnership/#sign-up-partners).

|  |  |
|  --- | --- |
| Billing date | Set at partner plan activation, recurs monthly |
| Timing | In arrears |
| Invoice amount | The standing charge or total sub-account usage, whichever is higher |
| Payment methods | Direct Debit or card |


Invoice amounts vary month to month with sub-account activity, and the standing charge sets the floor. Signable invoices the partner as a single account for usage across all sub-accounts. The partner bills its own end customers separately.

### Pricing the feature for your customers

Partners price and bill the feature independently of Signable. Signable does not prescribe how partners charge their customers. Common models include the following:

- **Per-envelope**: pass usage costs through to each sub-account.
- **Subscription tier**: include integrated eSignatures in a higher plan tier.
- **Credit bundles**: sell envelope credits in packs.
- **Absorbed cost**: provide eSignatures at no charge as a platform feature.


### Usage tracking using the API

| Purpose | Endpoint |
|  --- | --- |
| Retrieve usage for all sub-accounts, with current and previous period comparison | [`GET /usage`](/openapi/partners/getcompaniesusage) |
| Retrieve sub-account `company_id` values | [`GET /companies`](/openapi/partners/getcompanies) |