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.
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.
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.
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.
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 <API_TOKEN>header.
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": "<your-order-or-user-id>",
"content": { "type": "SIGN_UP" }
}'| Field | Description |
|---|---|
Authorization | 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. |
refId | Identifies the creator's link the visitor came from. The pixel captures it automatically from the influence360RefId query parameter on your destination URL; on your server, send back the same ref id (read it from the _influence360_ref_id cookie / your session). To test, use the Test ref id with "test": true. |
dedupKey | Your own stable id for this conversion (order id, user id). We use it to ignore duplicate reports if your server retries. |
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.
Run `claude` in your project, then paste this prompt.
I'm integrating Influence360 CPA conversion tracking into my backend using the server-to-server postback. Generate the code for my stack and explain where each piece goes.
CONTEXT
- An influencer 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 (envelope + per-type "content"):
{
"refId": "<the captured influence360 ref id>", // required; the campaign is resolved from this
"dedupKey": "<your stable order/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 (a stable order/user id) 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.