Integrations and CRM modules

Two directions, not one#

Under Admin, in the Property group, the Integrations & CRM modules pane sits at /admin?sel=integrations. The whole page is organised around two opposite flows, and the rest of it only makes sense once you separate them:

The inbound direction is what gives AdPix reports real revenue. The outbound direction is what tells your CRM which campaign each customer came from. A complete install has both, but either one works on its own.

The three steps the page itself names#

The first card, Connect a CRM in three steps, gives the order of work: download and activate the module, paste this page's connection values into the module's settings, and — optionally — add an outbound destination. The next three sections of the page are exactly those three steps.

Downloads#

The Downloads & docs card offers two things:

• WHMCS module — the companion addon as a .zip. If the module is not bundled on this server you see "not bundled on this server" instead of a button, and you will need to ask support for it.
• S2S API contract — the OpenAPI document. It is all you need for WooCommerce, WordPress or a home-grown CRM; the WHMCS module works against exactly the same contract.

Connection values#

The Connection details card offers three values with a copy button, and their names deliberately match the WHMCS module's fields:

Below that sits the Server keys — e-commerce S2S (identify / orders / attribution) card. A server key is bound to a data stream, and you tick the Scopes it needs when creating it. If you tick require HMAC, the same sk_ value is also the signing key — the WHMCS module wants it in its HMAC Secret field.

A data stream's write key — the one that appears in the tag snippet — is not a server key, and the server-to-server API does not accept it. The scopes, headers and error codes are covered in full in Server-side tracking.

The WHMCS addon#

The addon is bidirectional: it sends events to AdPix, and it receives attribution back from AdPix and keeps it next to the client record.

With Enable Capture on, the addon sends these moments:

The hooks read the first-party __sov_aid, __sov_ft and __sov_lt cookies to connect the order to the anonymous visit that happened before signup. For those cookies to exist on the billing domain, either you installed the tag there yourself or you turn on Inject Tracker. Never both — tagging twice means counting twice.

No hook can throw into the WHMCS request path. If AdPix is unreachable, your customer's signup or payment completes without a flicker; only the measurement of that moment is lost.

Reports inside WHMCS itself#

The addon adds a report page with Overview, Channels, Source / Campaign, First vs Last, New vs Returning, Cohorts, Clients, Unattributed and ROAS tabs. Revenue truth in those reports is WHMCS's own billing, joined to the local attribution by client ID — not a copy of AdPix's numbers. An AdPix summary card also sits on each client's admin record, showing the channel, source and campaign that acquired them.

Why one order is not counted twice#

An order can reach the CRM by two paths: once from the addon's hook, once from the worker's outbound delivery. Three guards keep it at one:

• The gate on the AdPix side. An event created by a URL-keyed event rule reaches CRM destinations only if it carries a transaction or order ID, or a positive value. Without that, every view of a "payment successful" page would register as an order in your CRM. Analytics reports are unaffected by the gate; their row was already written.
• The idempotency key on the receiving side. The addon's receiver extracts the order ID and invoice ID from the event's properties, and when an order ID is present it uses that as the idempotency key. The outbound delivery of the same order therefore lands on the row the local hook already created, instead of beside it.
• How the panel counts. The client card counts distinct orders, not purchase rows.

Any other CRM: the generic webhook#

Without WHMCS, the Generic webhook (any CRM / CMS) destination is the same contract without an addon. Fill in the Outbound delivery — AdPix → CRM card:

Your receiver gets a POST with a JSON body, and the shared secret arrives in the X-Sovereign-Secret header. What is sent is only user identifies and business events — page views and engagement events never go to a destination. The full body shape, HMAC signing and retry rules are in Webhooks and HMAC signing.

The Configured destinations table at the bottom lists each destination with its Target and a Status switch. To pause one, switch it off — deleting a destination also clears its pending deliveries.

Rotate secret generates a new shared secret and shows it once. The old one stops working immediately, so until you paste the new value into the receiver, deliveries are refused with an authentication error and sit in the retry queue.

Access required#

Viewing this pane needs report-read access, and server keys appear in the list by prefix only. Creating or deleting a destination, creating or revoking a key, and rotating a secret all require the edit-property-settings capability and are recorded in the audit log.

Frequently asked questions#

Related#