Resell Sigly with WHMCS

Sigly resellers run on prepaid seat credits:

• You buy a block of credits from Sigly at partner rates — your client pricing is entirely yours.
• Each active client account consumes credits monthly, deducted automatically from your balance on the account's renewal date.
• Your clients never see Sigly billing. They pay you through WHMCS as usual; their Sigly account just works.
• If your balance can't cover a renewal, that client account is suspended — never deleted — and reactivates automatically once you top up and unsuspend.

To become a reseller, email [email protected]. You'll get an API key and secret — the secret is shown once, so store it in your password manager. Seat pricing is in your reseller agreement.

Copy the sigly module folder (provided with your welcome email) into your WHMCS installation at:

<your-whmcs>/modules/servers/sigly/

No composer packages, no ionCube — it's a single self-contained provisioning module. After copying, it appears in WHMCS module dropdowns as Sigly Email Signatures.

In WHMCS go to System Settings → Servers → Add New Server and fill in:

• Module: Sigly Email Signatures
• Hostname: sigly.net (no https:// — the module always connects over HTTPS)
• Username: your reseller API key
• Password: your reseller API secret

Click Test Connection. A green result means your credentials work end to end; anything else, see troubleshooting below.

Go to System Settings → Products/Services → Create a New Product. Name and price it however you sell — per user, per company, bundled with your MSP plan; Sigly doesn't constrain your pricing.

On the Module Settings tab:

• Module Name: Sigly Email Signatures
• Package: Premium or Enterprise — the Sigly plan this product provisions
• App path: leave empty

Set the module to automatically set up the product as soon as the first payment is received — that's the whole point.

• Order paid → a Sigly account is created with the client's WHMCS name, email and service password, on the package you chose.
• Overdue / cancelled in WHMCS → the Sigly account is suspended or terminated to match. Suspension keeps all their signatures and settings.
• Upgrade/downgrade order → the Sigly package changes with it.
• Renewal invoice paid → the seat is renewed and, if it had been suspended for lack of credits, reactivated.
• Client area → your clients get a Log in to Sigly single sign-on button — no separate Sigly password to support.

Your clients then use everything a direct Premium customer gets: the builder, templates, Microsoft 365 and Google Workspace deployment, CSV team rollout, and open tracking.

Sigly bills seats monthly from your prepaid balance, whatever billing cycle you sell on. This happens two ways, and they can't collide: Sigly's own nightly run renews any seat that has come due, and a paid renewal invoice in WHMCS renews that seat immediately. Whichever happens first does the work; the other sees the seat isn't due and skips it, so a seat is never charged twice.

There's also a Renew / Sync Seat button on the admin service page if you ever need to trigger it by hand — handy right after topping up credits, to bring a suspended client straight back.

• Watch your balance. If it can't cover a renewal, that client is suspended until you top up.
• Top up by contacting your Sigly partner contact. Credits never expire.
• After topping up, suspended accounts reactivate when WHMCS next runs an unsuspend (or immediately via the service's Unsuspend button).

• Test Connection fails — check the hostname is exactly sigly.net (no protocol, no path) and the key/secret have no stray whitespace. The secret is only shown once at creation; if it's lost, ask us to rotate it.
• "That email already has a Sigly account" on create — the client signed up directly at some point. Contact us and we'll link or clear the account.
• Create succeeds but the client can't log in — use the SSO button from the WHMCS client area rather than the Sigly login form; reseller-provisioned accounts are designed to sign in through it.
• Everything else — WHMCS logs every module call under Utilities → Logs → Module Log (secrets are masked). Send us the failing entry and we'll take it from there.