Integrations
How conversion tracking works, and everything your account needs to run it.
Tokens & security
Two kinds of token authenticate your traffic, and four controls keep that traffic yours: allowed domains, request signing, IP allow-lists and rotation.
Keys the browser pixel. Meant to be visible in your page source — not a secret. Re-viewable any time; disable or rotate without touching your other tokens.
- Visibility
- Public — visible in page source
- Used by
- Browser pixel
- Sent as
- ?publicToken= query param
- Secret shown
- Not a secret · re-viewable
Authenticates server postbacks. The secret is shown only once when created or rotated, so store it securely and never expose it in the browser.
- Visibility
- Secret — server-side only
- Used by
- Server postback
- Sent as
- Authorization: Bearer …
- Secret shown
- Once, at create / rotate
Allowed domains
Each public token can include a domain allow-list. Events sent from pages on unapproved domains are silently discarded. The pixel still receives an empty success response, preventing attackers from learning which domains are allowed through probing.
An empty list allows all domains. Entries include subdomains, so example.com also covers shop.example.com.
Request signing (HMAC)
A private token can include an HMAC secret. Your server sends X-Timestamp and X-Signature (a hex HMAC-SHA256 of the timestamp, newline, and raw body). We verify both and reject mismatches, so the bearer token alone is not enough.
The X-Timestamp must be within a short tolerance of server time, which bounds replays; dedupKey then keeps an accepted conversion counted once.
IP allow-list
A private token can be restricted to a set of IP addresses or CIDR ranges. Postbacks from any other address are rejected regardless of credentials.
Combine with signing for defence in depth: the allow-list stops stray callers, the signature proves the payload came from you.
Rotation
Rotate a token whenever a secret may have leaked, when someone with access leaves, or on your regular security schedule. Rotation invalidates the old value immediately.
Keep two tokens per surface during planned rotations: add the new one, deploy, then revoke the old — zero downtime.
Content Security Policy
If your pages send a CSP, two directives are needed: the script host to load the pixel, and the collector host to report conversions. The pixel reports through sendBeacon, which is governed by connect-src — allowing only the script host loses every event with no error anywhere. Routing events through your own proxy (the collectUrl option) replaces the connect-src entry with your own host.
Content-Security-Policy:
script-src https://tracking-pixel.influence360.io;
connect-src https://tracking.influence360.io;Verify the bytes you loaded
Every published build is listed in the manifest with its size, build time and hashes — the same sha384 the pinned snippet carries. Hash the file the CDN served you and compare. Pinned builds are immutable and never republished, so a hash that matched yesterday still matches today.
curl -s https://tracking-pixel.influence360.io/manifest.json
curl -sO https://tracking-pixel.influence360.io/v<version>/influence360.js
openssl dgst -sha384 -binary influence360.js | openssl base64 -AHow long a pinned build stays available
A pinned URL is served for at least 24 months from its release and is never republished with different bytes — a fix ships as a new version instead. So a pinned integrity hash never breaks under you, and an alert from your script-monitoring tool always corresponds to a change you made. Each release is listed in the pixel changelog.