Integrations

In plain terms

A creator shares a link to your site. Someone clicks it, and later does something you care about — signs up, buys something, makes a deposit. Your site tells us it happened, we work out which creator sent that person, and the creator gets paid for it. The rest of this page is how each of those steps works.

Attribution

Every creator in a Performance (cost-per-action) campaign shares a unique tracking link. When a visitor clicks it, Influence360 records the click and forwards them to your destination URL. It adds a ref id to the web address — a short code identifying which creator sent that visitor. The pixel then stores the ref id in a cookie set on your own domain, so it is still there when the visitor converts.

When the visitor converts, you report the conversion together with the ref id — from the browser via the pixel, or from your server via the postback. Influence360 matches the ref id back to the creator, then runs its checks before crediting the conversion. It has to fall inside the attribution window — the time limit after a click for a conversion to still count. It also has to be new rather than a repeat of one already reported, and it has to clear our fraud checks.

Both routes run through the same validation, duplicate checks, fraud checks and minimum-value rules — a browser-reported amount is not discounted or scored more harshly. That is precisely why an amount you cannot vouch for should never be reported from the browser in the first place.

Attribution strictness for wallets

Web3 conversions are detected on the blockchain, from the visitor's crypto wallet. For a creator to be credited, that wallet has to be linked to the referral the visitor arrived with — a wallet binding. Attribution strictness decides how much a binding counts when the visitor signed it with their own wallet to prove they own it. New accounts require signed bindings by default; accounts created before that default prefer signed bindings but still count unsigned ones.

Strictness is a per-company setting — you change it on the Configuration tab under On-chain attribution.

Test mode

Events sent with the test flag are practice runs: they get the same reception checks as a real conversion — shape, token, ref id and duplicates — but are never matched to a campaign, never billed and never credit a creator. An accepted test therefore proves your integration reaches us, not that a campaign's amount tiers, plan ids or new-users rule will accept the live event. Your account has a dedicated test ref id, and the Configuration tab can fire a test event for you and confirm automatically when it lands.

The test ref id only works together with the test flag — real conversions must carry the ref id captured from the visitor's click.

• The event catalog is closedThe event types on this page are the complete list — there are no custom event types. A postback whose content.type is not a web2 event type is refused with HTTP 500 and the problem type tag:validation_error; the pixel accepts it and drops it. To pay for a milestone of your own, report it as the event whose pricing fits: a flat fee as any of SIGN_UP, KYC_VERIFICATION, APP_INSTALL, a fee per named level as SUBSCRIPTION with the level as qualifyingPlan, or a fee graded by an amount as PURCHASE, DEPOSIT. Creators see that event's name, so describe the real milestone in the action's description.
• One action per event typeA campaign carries at most one action for each event type, and a conversion is matched to that action by its type alone. One campaign therefore cannot pay two prices for the same event type — use a different event type or a second campaign. A conversion whose type the campaign has no action for is not credited.
• How each event is pricedFlat (SIGN_UP, KYC_VERIFICATION, APP_INSTALL, WALLET_ACTIVITY, NFT_MINT): every credited conversion earns the same amount. Amount tiers (PURCHASE, DEPOSIT, TOKEN_ACQUISITION, DEPOSIT_STAKE): the conversion earns the tier with the highest minimum its amount meets; below the lowest minimum it is not credited. Plans (SUBSCRIPTION): qualifyingPlan must equal one of the action's plan ids exactly — it is case-sensitive and there is no default plan — or it is not credited.
• dedupKey pays once per campaign and event typeA dedupKey is credited at most once per campaign and event type: an event whose key was already accepted for the same event type in the same campaign is rejected as a duplicate, whichever creator's link it came through. The same key on another event type, or in another campaign, counts on its own. A reversal (refund or chargeback) frees the key, so the user's next real conversion with it is credited again. Retries with the same key stay safe; give a repeat purchase or a re-subscription a new key. Leave dedupKey out and the pixel script (influence360.js) sends a key of its own for that page and browser session, so a reload or the Back button does not count twice — a direct request without one has no duplicate protection at all, and your own order or user id (e.g. deposit:order-1001) is always the better key. The postback requires one.
• New-users-only actions compare dedupKey across your companyOn an action marked new users only, dedupKey is also the user's identity: the conversion is refused when a conversion with the same key was already credited for your company, in any campaign. For such an action, build the key from the user rather than the order (e.g. deposit:user-42) — the event-type prefix keeps a user's earlier sign-up from counting against their first deposit. Without a dedupKey, every conversion counts as a new user.
• Other checks on a live conversionA live conversion is also refused when its ref id matches no creator's link, when a postback's token belongs to a different company than the campaign, when the campaign is not live (funded, or pending funding), when the creator's participation is not approved, when the latest click on the creator's link before the conversion — by any visitor, not necessarily the one converting — is older than the action's attribution window, when the conversion is the referring creator's own (the converting wallet, or a dedupKey containing it, is their payout wallet), or when fraud scoring flags a burst: more than 20 events on one ref id, or more than 50 from one IP address, that happened within 60 seconds — judged by when each event happened, not when it reached us. The per-IP limit does not apply to the postback, whose IP is your own server.
• Received is not creditedThe postback answers HTTP 202 once the request is received and its fields are valid; an invalid or unauthenticated request gets an explicit error instead. Everything else on this list is decided afterwards, and that outcome is not sent back to you. The pixel answers 204 to any well-formed request, whether or not the event is then kept.
• Test events check reception, not the campaignA test event (test: true) is kept out of billing entirely, so it is never matched to a campaign. It checks that the request is well-formed, carries a ref id, is not a duplicate and is not part of a burst — but not the campaign's action for that type, its amount tiers or plan ids, or new-users-only. An accepted test proves your integration reaches us; it does not prove the same live event will be credited.