Documentation Integrations

Connect Hubla

This guide connects Hubla to your SupremeTracking Node. When you finish, Hubla's sales, refunds and abandoned carts reach the Node by webhook, and the Loader writes the visitor's identifier into the checkout link, so each sale can be tied to the visit that brought it.

Two pieces work together:

  • The webhook: Hubla notifies the Node, server to server, for each event you tick in the rule. Each notification becomes a Supreme event.
  • The checkout link: while the module is active, the script served by the Loader writes the visitor's identifier into the pay.hub.la link, and Hubla returns that parameter in the sale notification.

The visitor's identifier is the STUID: a 32-character code the Node assigns to the visitor the Loader identifies. It is what ties a sale to the click, the campaign and the session it came from.

Labels from Hubla's panel are given in English, followed by the Portuguese label in parentheses.

Before you start

  • A Node on version 4.2.0 or newer. On an older Node, the module's Webhook tab says the Node must be updated.
  • A Property created in the Console. The Property is what receives the sales.
  • The Loader installed on the pages that carry Hubla checkout links. See Install the Loader.
  • A Hubla account with access to Integrations › Webhook (Integrações › Webhook).
  • Your Node's server must accept TLS 1.2: Hubla does not send webhooks over TLS 1.3 yet.

1. Install and turn on the Hubla module

  1. In the Console, open Integrations › Manage Modules, click Install module and install the Hubla module.
  2. When the install finishes, the Console asks whether you want to activate it now. Click Activate now: the module starts receiving sales and the checkout script goes into the Loader. Then the Hubla modal opens, with the Webhook, Checkout and Setup guide tabs.
  3. If you click Not now, the module stays off and the modal does not open. To come back to it, open Manage Modules, click Configure on the Hubla module and use Turn on at the top of the modal.

Turning the module on or off applies to every Property on this Node. While the module is off, link decoration and Initiate Checkout do not run, and webhook deliveries are refused.

2. Create the Property's address and the rule in Hubla

The address is the URL on your Node that receives Hubla's notifications for one Property. To create it, the Console asks for the Hubla token, so have it at hand first. Section 3 shows where it is.

In the Hubla modal, in the Console:

  1. On the Webhook tab, click Create address.
  2. Choose the Property, fill in Name (optional) if you want, paste the token into the Hubla webhook token field and click Create address.
  3. The Console shows a single URL, labeled All events. Copy it. Treat this URL like a password: anyone who has it can send events to this Property.

In Hubla:

  1. Open Integrations › Webhook (Integrações › Webhook, in the Automations section) and turn the integration on if it is not on yet.
  2. On the Settings tab (Configurações), click Add rule (Adicionar regra), give it a name (for example, Supreme) and paste the URL without changing anything. Hubla treats a redirect as a failure, so the URL must be exactly the one the Console showed.
  3. For products, choose All your products (Todos os seus produtos).
  4. Tick the events Invoice payment made (Pagamento da fatura realizado), Invoice refunded (Fatura reembolsada), Invoice status updated (Status da fatura atualizada), Invoice created (Fatura criada) and Abandoned cart (Carrinho Abandonado). If you sell subscriptions, also tick Automatic renewal disabled (Renovação automática desativada).
  5. Under "How to send your data" (Como enviar seus dados), choose Recommended integration (Integração recomendada).
  6. Save the rule.

What each ticked event becomes in Supreme:

Hubla event Supreme event
Invoice payment made purchase on the first sale; subscribe on a renewal. A renewal never counts as a new purchase.
Invoice refunded refund, with the sale's own transaction id, which removes its revenue from the Console's analysis.
Invoice status updated refund when the new status is chargeback. Every other status change is ignored.
Invoice created pix_generated or boleto_generated when the first sale generates a Pix or a boleto. A card invoice is ignored.
Abandoned cart lead, with the e-mail or phone the buyer typed into the checkout.
Automatic renewal disabled cancel_subscription.

Every other Hubla event is accepted and ignored by design; Hubla itself recommends ticking only what you use. A partial refund, Hubla reports only as a status change: it is not recorded, and the sale keeps its full value.

The rule sends notifications in Hubla's v2 webhook format ("version": "2.0.0"), which is what the module reads. A notification in any other version becomes a diagnostic on the Node, not a sale.

Why Recommended integration: in this mode, Hubla sends one notification per sale, carrying all of the sale's products, order bumps included. An older rule without the "How to send your data" field uses compatibility mode: sales still arrive, but order bump items are lost.

3. The token: where it is and where to paste it

  • Where it is: in Hubla, Integrations › Webhook › Authentication tab › Hubla Webhook Token (Integrações › Webhook › aba Autenticação › Hubla Webhook Token).
  • Where to paste it: into the address's Hubla webhook token field, in the Hubla modal in the Console (step 2 of the previous section).

The Node only accepts deliveries that carry the token saved on the address. With no token, or a different one, the delivery is refused and nothing is recorded. Hubla treats the refusal as a failure: it retries and, after a few days of failures, turns the rule off and tells you by e-mail. If the rule stops sending, check the token before turning it back on.

4. What the script does to the checkout link

While the module is active, the script served by the Loader looks for Hubla checkout links on the page and writes the visitor's identifier into them:

  • If the link has no src, the identifier goes into src.
  • If src is already yours, the identifier goes into sck.
  • If the link already uses both, it is not decorated, and a sale that comes from it arrives without the identifier. See Sale without the visitor identifier.

What the script does not do:

  • It does not touch your UTMs.
  • It never overwrites a value of yours, in any parameter.
  • It never leaves the same parameter twice in the link.
  • It does not change links to other domains.
  • It does not decorate the link until the Loader has identified the visitor.

When your src is already taken and the identifier goes into sck, that 32-character code shows up in Hubla's sck report. That is the cost of never overwriting your src.

Recognized links: only the direct checkout link, https://pay.hub.la/<offer-id>. The shortened link (hub.la/r/…) is not decorated, and neither is a checkout on your own domain. Use the direct link on your pages. The modal's Checkout tab shows the list under Recognized domains.

5. Initiate Checkout on the link click

The module also fires an Initiate Checkout when the visitor clicks a Hubla checkout link. In the Loader configuration, it shows as Initiate Checkout · via Hubla.

  • It is turned on and off per Property: on the modal's Checkout tab, choose the Property and use the Initiate Checkout switch. It comes on.
  • Turning it off does not affect link decoration: the sale can still be tied to the visit.
  • The change reaches new visitors within 1 hour.

6. Hubla's native pixel and Conversions API: double counting

Hubla also sends purchases and Initiate Checkout to Meta through its own pixel and Conversions API (CAPI). If your Property also forwards these events to the same Meta account through Supreme, Meta receives two purchases for the same sale.

The two cannot be deduplicated: Meta deduplicates by event id, and Hubla's webhook does not carry the id of the event its pixel sent. Pick one side:

  • turn off Hubla's native Purchase and Initiate Checkout; or
  • accept the double count.

7. Test the rule: the delivery shows as ignored

  1. In Hubla, in the rule list, open More options › Test configuration › Send events (mais opções › Testar configuração › Enviar eventos).
  2. Go back to the modal's Webhook tab, in the Console. The last delivery reads: Last delivery: ignored — a platform test or an event Supreme does not record. The URL and token are correct.

Hubla's test arrives with fictitious data and flagged as a test. The Node accepts the delivery but records nothing: the test never becomes a sale, does not show in Events and is not forwarded to any destination.

What the test proves: the URL and the token are correct. What it does not prove: that a real sale comes back with the visitor's identifier. Only the proof sale shows that (section 8).

If the test does not show up within a minute, check the token pasted into the address. Hubla's refund test can fail inside Hubla itself, without reaching the Node; if that happens, send it again.

8. Prove a sale end to end

The proof sale is the test that confirms, on your account, that a Hubla sale comes back with the visitor's identifier and is tied to the visit:

  1. Open your page with the Loader in a private window.
  2. Click the checkout link and check the Initiate Checkout in Events.
  3. Pay a low-value Pix.
  4. Check the purchase in Events, with the source of your visit.
  5. Refund the full amount and check the refund.

If the purchase arrives without the source of the visit, follow Sale without the visitor identifier.

Next steps