Integrations
How conversion tracking works, and everything your account needs to run it.
Set up the postback
Report conversions from your backend — authenticated, idempotent and reversible. Works with or without the browser pixel.
Use this for anything that decides money
Purchase and Deposit amounts set what a creator gets paid. Reported from your backend, the request is authenticated, the amount can be signed so nobody can alter it, dedupKey makes retries safe, and a refund can be reversed. None of that is possible from the browser pixel.
The values in angle brackets are placeholders. Sign in and the guide fills in your real endpoints and tokens.
1
Create an API token
Postbacks authenticate with a private API token. The secret is shown once, when you create or rotate the token — store it on your server and never expose it in the browser.
2
Capture the ref id
When a visitor arrives through a creator's link, our redirect appends ?influence360RefId=… to your destination URL. Store that value against the visitor (session, your own cookie or the user record) — you will send it back as refId with each conversion.
Also running the browser pixel? It already persists the same value in the _influence360_ref_id first-party cookie, so your server can read it from there instead.
3
Send the postback
POST a JSON body with the ref id and the conversion details — the campaign is resolved from the ref id.
- When the user converts, POST a JSON body with the ref id and a
contentobject holding the conversion (itstypeplus that type's own fields). The campaign is resolved from the ref id. - Authenticate the request with the
Authorization: Bearer <YOUR_PRIVATE_TOKEN>header.
Sign-up (SIGN_UP)
Sign-up
SIGN_UPA new user registers on your product.
No event-specific fields — content carries only its type
postback.sh
curl -X POST 'https://tracking.influence360.io/public/postback/conversion' \
-H 'Authorization: Bearer <YOUR_PRIVATE_TOKEN>' \
-H 'Content-Type: application/json' \
-d '{
"refId": "<REF_ID>",
"dedupKey": "sign_up:<order-or-user-id>",
"content": { "type": "SIGN_UP" }
}'Request fields
The common fields sit at the top level of the request; the event-specific ones go inside the content object, selected by its type. There is no top-level event field.
| Field | Description |
|---|---|
AuthorizationRequired | Authenticates your server. The secret is shown only once when you create or rotate a token — paste your stored secret in place of <YOUR_PRIVATE_TOKEN>. Lost it? Rotate the token on the Tokens page. |
refIdRequired | The ref id captured from the creator's link — the campaign and creator are resolved from it. |
contentRequired | The event-specific object. Its type field selects the event and gates which other fields it carries — see the event details above. |
dedupKeyRequired | Your id for this conversion — an order or user id, prefixed with the event type (e.g. purchase:1001). It is credited once per campaign and event type, and a refund frees it. Required on the postback — it is what makes retries safe; strongly recommended on the pixel, whose script otherwise uses a key of its own for the browser session. |
testOptional | Marks a verification canary: checked on receipt but never matched to a campaign or billed. See “How a conversion is credited” for what it does not check. |
reversalOptional | Set true to reverse a previously reported conversion (refund or chargeback). |
clientEventAtMsOptional | Optional epoch-millis timestamp of when your side observed the event. Diagnostic only — we record the authoritative time on receipt, so it never affects billing or attribution; it just helps you spot delivery lag on queued or retried events. |
Money values inside content are strings, e.g. "49.99" — the same in the pixel's JS API and in the postback body.
Or delegate the work
Integrate with an AI assistant
Prefer to delegate? Paste this prompt into your AI coding assistant — it describes this integration end to end: the endpoint, every event type and the exact request body.
Select your client
Run `claude` in your project, then paste this prompt.
integration-prompt.md
I'm integrating Influence360 Performance conversion tracking into my backend using the server-to-server postback. Generate the code for my stack and explain where each piece goes.
CONTEXT
- A creator link sends a visitor to my site with ?influence360RefId=<ref id> appended to the destination URL.
- CAPTURE: when a visitor lands, read that query parameter and store it against the visitor (session, cookie or user record) — it is sent back as refId with each conversion. (If the Influence360 browser pixel also runs on the site, it persists the same value in the _influence360_ref_id first-party cookie, which the server can read instead.)
- REPORT: when the user converts, POST the conversion from my backend.
POSTBACK — POST https://tracking.influence360.io/public/postback/conversion
Headers: Authorization: Bearer <MY_API_TOKEN> (server-side only), Content-Type: application/json
JSON body (top-level fields + per-type "content"):
{
"refId": "<the captured influence360 ref id>", // required; the campaign is resolved from this
"dedupKey": "<event-type>:<order-or-user-id>", // required; idempotency — a retry with the same key is counted once
"reversal": false, // optional; true to reverse a prior conversion (refund/chargeback)
"test": false, // optional; verification canary, never billed
"content": { "type": "<EVENT_TYPE>", ... } // required; type-specific fields, see catalog below
}
Postback "content" shape per type:
- SIGN_UP — a new user registered; content: { "type": "SIGN_UP" }
- KYC_VERIFICATION — a user passed identity verification; content: { "type": "KYC_VERIFICATION" }
- APP_INSTALL — a user installed the app; content: { "type": "APP_INSTALL" }
- PURCHASE (orderValue required) — a paid order (orderValue = order amount); content: { "type": "PURCHASE", "orderValue": "49.99" }
- DEPOSIT (depositValue required) — a funded deposit (depositValue = deposit amount); content: { "type": "DEPOSIT", "depositValue": "49.99" }
- SUBSCRIPTION (qualifyingPlan required) — a paid subscription (qualifyingPlan = the plan the user subscribed to; payout is plan-driven); content: { "type": "SUBSCRIPTION", "qualifyingPlan": "pro-monthly" }
NOTES
- Keep the API token server-side only; never expose it in the browser.
- Always send dedupKey (<event-type>:<order-or-user-id>, see below) so retries don't double-count.
- Monetary events must send their type-specific amount field (PURCHASE → orderValue, DEPOSIT → depositValue); it has to meet the action's configured minimum or the conversion is rejected.
- SUBSCRIPTION must send qualifyingPlan (the plan the user subscribed to); its payout is decided by matching that plan against the action's configured plan tiers — an unlisted plan is rejected — so it carries no amount.
- Web3 events (WALLET_ACTIVITY, TOKEN_ACQUISITION, DEPOSIT_STAKE, NFT_MINT) are DETECTED on-chain — never postback them. Attributing one needs the visitor's wallet tied to the referral, which happens in the browser, not here: run the influence360.js pixel on the destination page and call influence360('identify', '<connected-wallet-address>', { chain: 'ETHEREUM' }) after the wallet connects.
- THE EVENT TYPES ABOVE ARE THE COMPLETE CATALOG — there are no custom event types, and an unknown content.type is refused (postback) or silently dropped (pixel). If I need to pay for a milestone that is not in the list, map it onto the event whose pricing fits — a flat fee: any of SIGN_UP, KYC_VERIFICATION, APP_INSTALL; a fee per named level: SUBSCRIPTION with the level as qualifyingPlan; a fee graded by an amount: PURCHASE, DEPOSIT — and tell me which one you chose and why. Never invent a type.
- A campaign carries at most one action per event type, and a conversion is matched to it by its type alone, so the same type cannot be paid at two prices in one campaign.
- dedupKey PAYS ONCE PER CAMPAIGN AND EVENT TYPE: a key already accepted for the same event type in the same campaign is rejected as a duplicate, whichever creator's link it came through, and a reversal (refund or chargeback) frees it again. Build every key as <event-type>:<id> (e.g. deposit:order-1001), give a repeat purchase or re-subscription a new key, and send the same key only on a retry of the same event. On an action marked new users only the key is also the user's identity (compared across all of my company's campaigns and event types — hence the event-type prefix), so there build it from the user id (e.g. deposit:user-42). Tell me which ids you chose. Without a dedupKey there is no duplicate protection beyond the pixel script's own per-session key.
- A 202 from the postback means RECEIVED, not credited: amount tiers, plan ids, the campaign's actions, new-users-only, the attribution window and fraud burst limits (more than 20 events per ref id or 50 per IP that happened within 60 seconds; the per-IP limit does not apply to the postback) are applied afterwards and the outcome is not reported back. A test event (test: true) is never matched to a campaign, so an accepted test does not prove any of those will pass — list them in your summary as things for me to confirm in the campaign's configuration.