Awin integration is the process of connecting a cashback or coupon platform’s publisher account to Awin’s two separate systems, the transaction API and the product datafeed, so that advertiser data, click tracking and commission status all flow into the platform automatically. Done properly, a user’s purchase becomes a correctly-stated pending balance within minutes and a withdrawable one only once Awin confirms it. Done carelessly, it becomes the reason a cashback platform pays out money it never actually earned.

This guide covers what an Awin integration actually involves at the data and engineering level: what the API gives you, what the datafeed gives you, how the two map onto a cashback platform’s data model, what Awin looks for before approving a publisher, and the failure modes that show up months after launch rather than on day one.

What Awin Integration Actually Connects #

Awin is one of the larger affiliate networks operating in the UK and continental Europe, sitting between advertisers (the retailers and brands running affiliate programmes) and publishers (the cashback sites, coupon sites and content publishers that drive traffic to them). Connecting Awin to a cashback website means building a bridge between your publisher account and your platform across three separate channels:

• Catalogue in, product, pricing and voucher data flowing from Awin’s datafeed system into your store pages.

• Clicks out, a user clicking a store on your site gets redirected through an Awin tracking link that carries an identifier back to your platform.

• Transactions in, Awin reports back which of those clicks resulted in a sale, at what commission, and at what confirmation status.

A working Awin integration means all three channels run on a schedule without manual intervention, and that a transaction’s status change from Awin, pending, approved or declined, is reflected in a user’s balance correctly and promptly.

Awin API Integration vs Awin Datafeed Integration #

The single most common design mistake in an Awin build is treating “integrating Awin” as one task. It is two, and they do not overlap:

• The API carries money data: advertisers, transactions, commission amounts and statuses.

• The datafeed carries catalogue data: products, prices, images and voucher codes.

Both live behind the same login: the Awin publisher platform is where you generate API credentials, browse joined advertisers, and pull datafeed URLs. Confusing which one a given piece of data comes from is the most common source of a stalled Awin integration.

	Publisher API	Product Datafeed
What it returns	Advertisers, transactions, commission amounts, statuses	Products, prices, images, voucher codes
Authentication	OAuth2 Bearer token	Feed URL with access token, per advertiser
Refresh pattern	Scheduled polling on a rolling window	Scheduled import, typically daily
Drives	User balances and commission reporting	Store pages and voucher listings
Rate limits	Yes, poll from a queued job, not on request	Feed-specific, generally generous
Where it breaks if skipped	Balances never update; users see nothing after clicking	Store pages go stale or empty; nothing to click on

An Awin integration for a cashback site therefore means building two separate pipelines that happen to share one account: a datafeed pipeline that keeps the catalogue current, and an API pipeline that keeps commission and balance data current. Treat them as separate jobs with separate schedules, separate failure alerts and separate retry logic. A datafeed outage and an API outage look identical to a user, nothing updates, but they require different fixes.

The Data Model: Mapping Awin Fields to Your Platform #

Once the two pipelines are running, the harder problem is deciding what each Awin field actually means inside your own schema. This is the part most integration guides skip, and it’s where the real engineering decisions live.

Awin Field	Maps To	Why It Matters
id	External transaction ID	Your deduplication key. Store it as unique, a re-sync without this constraint will double-credit users on every retry.
clickRef	Internal click ID to user ID	The only reliable link between a transaction and the person who earned it. Set it on every single deeplink without exception, or the transaction arrives with nowhere to go.
advertiserId	Store record	Determines which store the user sees in their activity feed and which cashback rate applied at the time of the click.
commissionAmount	Gross commission (internal)	Your revenue before the user’s share. This figure should never be exposed in any user-facing view.
saleAmount	Order value (user-facing)	Displayed to the user so they can recognise their own purchase in their activity history.
commissionStatus	Wallet state	pending, approved, declined map to pending, confirmed, reversed.
transactionDate	Earned-on date	Drives the claim window a user sees. Anything older than this that never appeared becomes a support ticket.
validationDate	Confirmed-on date	Starts the payout-eligibility clock, not the transaction date, which is a common source of premature payouts.
currency	Transaction currency	Convert at one fixed point in the pipeline. Converting inconsistently, sometimes at transaction time, sometimes at payout time, produces balances that no longer reconcile against Awin’s own reporting.

DESIGN PRINCIPLE Model transactions as an append-only ledger, not a mutable balance column. Every status change from Awin, pending to approved, or pending to declined, writes a new ledger entry rather than overwriting the previous one. A mutable balance field cannot tell you why a number changed six weeks later; a ledger can, and that difference is what makes a payout dispute resolvable instead of a guess.

The three balance states worth keeping separate in the schema, not just in application logic:

• Pending, visible to the user, contributes to their displayed total, not withdrawable.

• Confirmed, Awin has reported approved, the amount is locked in.

• Withdrawable, confirmed and past any platform-side hold period you apply on top of Awin’s own validation window.

Collapsing these into one field is the single most common structural mistake in a cashback data model, and it is very difficult to unwind after real user balances already exist in the wrong shape.

Awin Cashback Publisher Approval #

Awin cashback publisher approval happens before any of the technical integration is possible, you need an active publisher account to generate API credentials at all. Awin reviews the site itself rather than the application form, and the most common cause of rejection is applying before the platform is genuinely ready. What reviewers look for:

•  A live site on its own domain with real store pages, not a staging URL or a coming-soon page.

•  A visible cashback mechanic, a reviewer should be able to see how a user earns and how they get paid without creating an account first.

•  A real privacy policy, written for the actual site, naming what is tracked and why. The disclosure standard Awin expects lines up closely with the FTC’s endorsement guidance for affiliate relationships generally, worth reading even if you’re outside the US.

•  A working contact route, a monitored email address and a clear company identity.

•  Original store content, thin or duplicated descriptions across hundreds of stores read as an unfinished catalogue import.

•  Clear disclosure of traffic sources, undisclosed toolbar, extension or incentivised traffic is a fast route to a decline.

Individual advertisers within Awin approve publishers separately from the network-level approval, and can decline or later remove a publisher from their own programme. A cashback platform’s advertiser list is therefore not fixed once integration is live, it needs to react to programme status changes on an ongoing basis, not just at setup.

Deeplinks and Click Tracking #

A deeplink is the tracking URL a user follows from your store page through to the advertiser. Connecting Awin to a cashback site requires generating these dynamically rather than storing static links, since links need to carry a fresh click reference on every request. The structure is built from three parts:

1.    Your Awin publisher ID

2.    The advertiser’s Awin ID

3.    The destination URL, plus a clickRef parameter set to your internal click identifier

Awin also supports additional click reference slots beyond the primary clickRef, which can carry campaign, device or placement data for reporting without interfering with the user-matching function of the primary reference. Templates should be cached rather than rebuilt from scratch on every click, and destination URLs should be validated periodically, advertisers change domains and paths without notice, and a stale deeplink template silently sends users to a 404 while still recording a click.

Transaction Sync and Status Handling #

The transaction lifecycle runs on a predictable path: a user clicks a store link, a deeplink carrying a click reference is generated and redirects through Awin to the advertiser. On purchase, Awin records a pending transaction. Your platform polls the Awin API on a schedule, matches the transaction to the click, and credits a pending balance. After the advertiser’s validation window, typically 30 to 90 days, Awin marks the transaction approved or declined. Approved moves the balance to confirmed and withdrawable; declined reverses it. Our broader guide to affiliate commission tracking covers this same pending-to-confirmed pattern across other networks, if you want the comparison.

Stage	What Happens	Wallet State
Click	User clicks a store link on your site; deeplink built with clickRef	No balance yet
Redirect	Awin redirects to the advertiser	No balance yet
Purchase	User completes a purchase	No balance yet
Awin reports transaction	Your platform polls the API and matches the transaction to the click via clickRef	Pending (visible, not withdrawable)
Validation window closes	Advertiser confirms or declines, typically 30 to 90 days later	Approved → Confirmed / Withdrawable. Declined → Reversed

Transaction sync should run as a queued background job on a fixed interval, polling a rolling window rather than the full transaction history on every run. For each transaction returned:

4.    Check the external transaction ID against existing records, skip if already processed, to avoid double-crediting on retries.

5.    Match clickRef to an internal click and user. Log unmatched transactions for manual review rather than discarding them silently.

6.    Write a new ledger entry reflecting the current commissionStatus, rather than mutating a prior entry.

7.    Recompute the user’s pending, confirmed and withdrawable totals from the ledger.

Reversals, Validation Windows and Payout Risk #

Awin’s validation period is set by the individual advertiser, not by Awin as a network, and commonly runs 30 to 90 days from the sale date, longer for travel and categories with high return rates. During this window a transaction can move from pending to either approved or declined. A declined transaction is a reversal: the sale did not stand, whether from a cancellation, a return, or a fraud check. If reported transactions seem to lag rather than reverse outright, our note on cashback tracking and notification delays covers how to tell the two apart.

WHERE PAYOUTS ACTUALLY GO WRONG The most expensive design mistake in a cashback integration is allowing a user to withdraw against a pending balance. If a platform pays out before Awin confirms the transaction, and the transaction is later declined, that money has already left the platform with no recourse to recover it from the user. Holding withdrawal eligibility strictly to the confirmed state is not a conservative choice, it is the only version of the data model that cannot lose money on a reversal.

This also means the site’s own hold period, if any, can legitimately sit on top of Awin’s validation window rather than replacing it. Some platforms add a short additional buffer after confirmation before enabling withdrawal, purely to absorb rare late-stage reversals that arrive just after approval.

Common Awin Integration Mistakes #

•      Polling the API from a web request instead of a background job. This hits rate limits fast and makes sync reliability dependent on page traffic.

•      Treating clickRef as optional on some deeplinks. Any deeplink generated without it produces a transaction with no way back to a user.

•      Converting currency inconsistently. Pick one conversion point, transaction time or payout time, and apply it everywhere, or balances stop reconciling against Awin’s own reports.

•      Ignoring commission rate changes in the datafeed. Advertisers adjust rates without notice; without monitoring, a platform’s published rate can silently exceed what it actually earns.

•      Assuming advertiser approval is permanent. It is granted and can be withdrawn per advertiser, independent of the network-level publisher account.

•      Treating a mutable balance field as sufficient. Without a ledger, a support query about a missing or incorrect balance has no audit trail to investigate.

Awin Alongside Other Affiliate Networks #

Awin rarely runs alone. Most cashback platforms of any scale integrate several networks, CJ Affiliate, Rakuten Advertising and Impact.com among the common combinations, to cover advertisers Awin doesn’t carry and to give users more stores to browse. Our overview of affiliate network integration covers the general architecture question before you get into any single network’s specifics. Running multiple networks introduces a problem specific to that setup: the same purchase can be reported by two networks at once, if a user’s click somehow gets tracked in both.

The reliable fix is deduplicating on merchant order ID within a timestamp window, not on the network’s own transaction ID, since the transaction ID differs per network for what is actually the same sale. Network-specific transaction IDs are useful for reconciliation against each network’s own reporting, but they cannot be used alone to detect a duplicate across networks.

A NOTE ON SHAREASALE ShareASale is a name that still comes up in this context, but it is worth being precise about its current status. Awin acquired ShareASale in 2017, and completed migrating every active ShareASale account onto the Awin platform, with the standalone ShareASale service closing in October 2025. A cashback platform planning a new integration today is integrating with Awin directly, using the same publisher API and datafeed system covered in this guide, whether the merchant relationship originally came from Awin or from a legacy ShareASale account.

FAQ #

Conclusion #

Awin integration is straightforward in outline and easy to get wrong in the details that don’t show up until a reversal or a rate change happens for the first time. The two data sources, the API and the datafeed, need separate pipelines. The data model needs three distinct balance states backed by a ledger, not a single mutable balance. Publisher approval depends on the site being genuinely finished before you apply. And if you’re running more than one network, deduplication has to happen on order data, not on either network’s own transaction ID. Get those decisions right early, and the ongoing maintenance is mostly monitoring feeds and rate changes rather than firefighting balances. If you’d rather have a team that has already made these decisions build it into your platform, that’s the service we offer, but everything above is enough to build it yourself if that’s the route you’d rather take.