Integrations

How conversion tracking works, and everything your account needs to run it.

Event reference

The complete catalog of conversion events, with the exact request each one needs. Web2 events are reported by you, from the browser or your backend; web3 events are detected on-chain and never sent.

Request envelope

Both transports share one shape: the common fields live in the envelope, and the event-specific fields live inside the content object, selected by its type. There is no top-level event field.

FieldBrowser pixelServer postbackDescription
refIdRequiredRequiredThe ref id captured from the creator's link — the campaign and creator are resolved from it.
contentRequiredRequiredThe event-specific object. Its type field selects the event (catalog below) and gates which other fields it carries.
publicTokenRequiredYour public token (browser key), sent as the ?publicToken= query parameter on the request URL — not in the JSON body. Identifies your company and is checked against the token's allowed domains.
dedupKeyRecommendedRequiredYour stable id for this conversion (order or user id). Required on the postback — it is what makes retries safe; strongly recommended on the pixel.
testOptionalOptionalMarks a verification canary — validated through the full pipeline but never billed.
reversalOptionalSet true to reverse a previously reported conversion (refund or chargeback).
clientEventAtMsOptionalOptionalOptional 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.
eventSourceUrlOptionalThe page URL the event fired on. The pixel script captures it automatically — you only set it yourself when posting to the pixel endpoint directly. Diagnostic only; never used for billing or attribution.
Authentication differs

The pixel carries your public token as the ?publicToken= query parameter on the request URL (not in the body); the postback authenticates with the Authorization Bearer header (plus optional request signing and IP rules).

Money values inside content are strings, e.g. "49.99" — the same in the pixel's JS API and in the postback body.

Web2 events — you report these

You report these from your website (pixel) or backend (postback). Pick a transport to see the exact request for each event.

Sign-upSIGN_UP

A 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": "<your-order-or-user-id>",
    "content": { "type": "SIGN_UP" }
  }'
KYC verificationKYC_VERIFICATION

A user completes identity verification (KYC).

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": "<your-order-or-user-id>",
    "content": { "type": "KYC_VERIFICATION" }
  }'
App installAPP_INSTALL

A user installs your mobile app.

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": "<your-order-or-user-id>",
    "content": { "type": "APP_INSTALL" }
  }'
PurchasePURCHASEValue-gatedPostback recommended

A user makes a purchase. Send the order amount as orderValue.

Event-specific fields
orderValueRequiredThe conversion amount, as a JSON string (e.g. "49.99"). Must meet the action's configured minimum, or the conversion is rejected.
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": "<your-order-or-user-id>",
    "content": { "type": "PURCHASE", "orderValue": "49.99" }
  }'
DepositDEPOSITValue-gatedPostback recommended

A user funds their account. Send the deposit amount as depositValue.

Event-specific fields
depositValueRequiredThe conversion amount, as a JSON string (e.g. "49.99"). Must meet the action's configured minimum, or the conversion is rejected.
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": "<your-order-or-user-id>",
    "content": { "type": "DEPOSIT", "depositValue": "49.99" }
  }'
SubscriptionSUBSCRIPTIONPlan required

A user starts a paid subscription. Send the plan they subscribed to as qualifyingPlan — the payout is decided by matching it against the action's plan tiers, so no amount is sent.

Event-specific fields
qualifyingPlanRequiredThe identifier of the plan the user subscribed to (e.g. "pro-monthly").
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": "<your-order-or-user-id>",
    "content": { "type": "SUBSCRIPTION", "qualifyingPlan": "pro-monthly" }
  }'

Web3 events — detected on-chain

Detected on-chain by watching the contract configured on the action — you never send these. A postback carrying one of these types is rejected outright; a pixel carrying one is dropped during attribution. Either way it is never credited.

Detected is not the same as credited: the chain does not say who referred the wallet. You have to bind the connected wallet to the referral with the pixel's identify call, or these conversions are never attributed to a creator. Set up web3 tracking

Wallet activityOn-chain
WALLET_ACTIVITY

A wallet interacts with your configured contract.

Detected on-chain — no pixel or postback needed.
Token acquisitionOn-chain
TOKEN_ACQUISITION

A wallet acquires at least the configured minimum amount of your token.

Detected on-chain — no pixel or postback needed.
Deposit / stakeOn-chain
DEPOSIT_STAKE

A wallet deposits or stakes at least the configured minimum into your contract.

Detected on-chain — no pixel or postback needed.
NFT mintOn-chain
NFT_MINT

A wallet mints from your configured NFT collection.

Detected on-chain — no pixel or postback needed.