CJ Advertiser Tracking API Guide

What it is

The advertiser tracking API is a way to tell CJ that a sale happened by sending a message from your own server, rather than dropping a snippet of code on your order-confirmation page and hoping it runs. The industry name for this is server-to-server tracking, often shortened to S2S or "postback." Both ends are computers: your server speaks directly to CJ's server, with no browser in the middle.

Here's an analogy. Imagine a delivery driver who has to drop a signed receipt back at head office. The browser pixel is like asking the customer to post that receipt for you — most of the time it arrives, but sometimes they lose it, the letterbox is full, or they never bother. Server-to-server tracking is like the driver radioing head office directly the moment the parcel is handed over. You're not depending on the customer to do anything; the confirmation comes straight from a source you control.

Why it matters

A browser pixel only works if the right page loads fully in the customer's browser and nothing interferes with it. In reality, plenty interferes. Ad blockers strip out tracking scripts. Privacy-focused browsers limit what third-party code can do. Some shoppers close the tab the instant their payment goes through, before the confirmation page finishes loading. On mobile, a flaky connection can stop the pixel firing at all. Every one of those is a sale your affiliate partner drove that quietly vanishes from CJ's reporting.

That under-reporting is corrosive. Partners see fewer conversions than they actually generated, decide your programme converts poorly, and shift their effort to a competitor. Meanwhile your own numbers understate how well affiliate is performing, so the channel gets starved of budget internally. Server-to-server tracking closes that gap by reporting the sale from your back end, where you already have a clean, confirmed record of the order. It's also the more durable choice as browsers keep tightening privacy rules year after year.

How it works

From your side as the advertiser — the brand running the programme — the flow looks roughly like this:

1. Capture the click identifier. When a customer arrives from a CJ link, CJ passes a unique identifier for that click. Your site needs to grab it and hold onto it (commonly in a first-party cookie or your session) so you can connect it to the order later.
2. Wait for a genuinely confirmed sale. Don't fire on the click or on "add to basket." Trigger only when the order is truly complete — payment captured and recorded in your own system.
3. Build the conversion record on your server. Assemble what CJ needs to credit the sale: the stored click identifier, the order value, the order reference, and which programme or item it belongs to.
4. Send the call server-to-server. Your back end sends that record directly to CJ's endpoint. No browser is involved, so nothing the shopper does (or blocks) can stop it.
5. Read CJ's response and log it. CJ replies to confirm it received and accepted the conversion. Store that response so you have your own audit trail if a figure is ever queried.
6. Reconcile against your store records. Periodically match the sales you sent against the sales CJ recorded. Any gap points to something misfiring, and you'll spot it before a partner does.
7. Handle returns and cancellations. Decide how you'll tell CJ when an order is later refunded or cancelled, so you aren't paying commission on revenue that didn't stick.

You don't have to throw the pixel away to do this. Many brands run both: the pixel catches the simple cases instantly, and the server call acts as the reliable backstop. The key is to make sure the same sale isn't counted twice — your setup needs a clear rule for which source is the source of truth.

Common mistakes

• Double-counting sales. Running the pixel and the API without a deduplication rule means CJ can record the same order twice, inflating commissions and your stats. Pick one source as authoritative and pass a shared order reference so duplicates can be matched and dropped.
• Losing the click identifier. If your site never stores the identifier CJ passed on the inbound click, the server call has nothing to attribute the sale to. Confirm it's captured the moment the customer lands and survives all the way to checkout.
• Firing too early. Sending the conversion at basket or pending-payment stage credits sales that may never complete. Only call the API once the order is genuinely paid and final.
• Ignoring refunds. Reporting every sale but never reporting the returns means you slowly overpay partners. Build the cancellation path in from day one, not as an afterthought.

Reporting tips

Once server-side tracking is live, the most valuable habit is regular reconciliation. At least weekly, line up the orders your own e-commerce platform recorded against the conversions CJ shows. They should track closely. A persistent shortfall on CJ's side usually means some calls are failing silently; a surplus usually means double-counting. Either way, you want to catch it early, while the numbers are small enough to fix cleanly.

Watch the time gap between an order completing and the conversion appearing in CJ. With server-to-server tracking it should be near-instant, so a growing lag is an early warning that your queue or endpoint is struggling. It also helps to keep your own log of every call and CJ's response — when a partner queries a missing sale, being able to show "we sent it at this time and CJ accepted it" turns a dispute into a five-minute lookup. Finally, tag conversions by source so you can prove, internally, how many sales the server path rescued that the pixel would have dropped.

When to use / when not to use

Related guides

← Back to CJ (Commission Junction) hub

Frequently asked questions