Rakuten Postback API Setup

Quick Answer A Rakuten postback (also called server-to-server or S2S tracking) is your server quietly telling Rakuten's server "a sale just happened" — instead of relying on a pixel that loads in the shopper's browser. You'd use it when browser-based tracking is leaking conversions: blocked cookies, ad-blockers, or checkouts that skip the usual thank-you page.

What a postback actually is

Picture two ways to report a sale. The old way is to drop a little tracking image on your order-confirmation page — when the browser loads that image, Rakuten records a conversion. It works, but it depends entirely on the shopper's browser behaving: cookies enabled, scripts allowed, the confirmation page fully loading. In 2026, that's a lot of "ifs."

A postback skips the browser altogether. When an order is confirmed on your servers, your system fires a small, invisible web request directly to Rakuten's tracking endpoint with the order details attached. Think of it as the difference between hoping a guest mails back the RSVP card (browser pixel) versus your own front desk phoning the venue the moment they arrive (postback). One depends on the guest; the other you control.

The key ingredient that makes it possible is a tracking identifier Rakuten hands back when the shopper first clicks an affiliate link. You store that identifier, and when the sale completes, you send it back to Rakuten in the postback so they can match the sale to the affiliate who earned it.

Why it matters to your programme

Every conversion a browser pixel fails to record is a sale your affiliates worked for but never got paid on. When that happens enough times, your best partners notice their reported conversion rate is mysteriously low, lose faith in the programme, and quietly push your offer down their site. Under-tracking doesn't just cost you data — it costs you relationships.

Postback tracking is the single most reliable way to close that gap. Because the report comes from your server, it's immune to ad-blockers, Safari's cookie restrictions, and the shopper bouncing off the confirmation page before the pixel loads. For programmes with mobile-app checkouts, subscription flows, or any journey where there isn't a clean "thank you" page, a postback is often the only way to track accurately.

How to set it up, step by step

Capture the click identifier. When a shopper arrives from a Rakuten affiliate link, Rakuten appends a tracking value to your landing URL. Grab it on arrival and store it against that visitor's session.
Carry it through to the order. Pass that identifier through your funnel so it's still attached when the order is finally confirmed. A first-party cookie or your session store both work — just make sure it survives the journey.
Build the postback request. When the order completes server-side, assemble a request to Rakuten's tracking endpoint containing the order ID, sale amount, currency, and the stored click identifier.
Fire it from your server, not the browser. Send it the moment your system marks the order as confirmed and paid — this is the whole point, so don't be tempted to trigger it from front-end JavaScript.
Send a unique order ID every time. Rakuten uses it to recognise and discard duplicates, which protects you from double-counting if the request gets retried.
Handle the response. Log whether Rakuten accepted the postback. If it errors, queue it and retry rather than dropping the sale on the floor.
Test with a real click. Click a live affiliate link yourself, complete a test order, and confirm the conversion shows in Rakuten's dashboard with the right value and affiliate attributed.
Reconcile before going live. Run postback and pixel side by side for a week and compare the numbers before you switch the pixel off.

Common mistakes

Firing the postback from the browser. If you trigger it with client-side JavaScript, you've rebuilt the exact problem you were trying to escape. It must come from your server.
Losing the click identifier mid-funnel. If the tracking value isn't carried from landing page to checkout, the sale arrives with nothing to attribute it to. Test the full journey, not just the endpoint.
Reusing order IDs. Sending the same order ID twice, or a non-unique one, leads to either rejected or double-counted sales. Use your real, unique order reference.
Sending before payment clears. Firing the postback at "order placed" rather than "order confirmed" inflates your numbers with sales that later cancel — and creates messy clawbacks down the line.

Reporting tips

Once postback is live, the number to watch is the gap between orders in your own checkout system and conversions Rakuten reports. They'll rarely match to the penny — returns, cancellations, and out-of-network sales all account for legitimate differences — but the gap should be small and stable. A sudden widening usually means the postback has broken: a deploy changed your checkout, the identifier stopped being captured, or your endpoint started erroring.

In the Rakuten dashboard, check that conversions are landing with the correct sale amount and currency, and that they're attributed to the right affiliate rather than dumping into an "unattributed" bucket. If amounts look rounded or zeroed, your postback is probably sending the wrong field. Build a simple weekly check comparing your order count to Rakuten's so a tracking break gets caught in days, not at month-end reconciliation.

When to use it — and when not to

Use a postback when…	You may not need one when…
Your checkout has no reliable confirmation page (apps, one-page or subscription flows).	You have a clean thank-you page and tracking already reconciles well.
Browser pixels are clearly under-counting versus your own sales data.	You have no server-side development resource to build and maintain it.
A large share of traffic is on Safari, iOS, or uses ad-blockers.	Your volume is tiny and the engineering effort outweighs the leakage.
You want tracking you fully control and can debug from your own logs.	You're still validating the programme and haven't picked a tracking approach yet.

Frequently asked questions

Do I have to remove my Rakuten tracking pixel if I add a postback?

Not immediately. Run both in parallel for a week or two and compare the numbers. Once you're confident the postback is reporting accurately, switch to it as your primary method so you're not double-counting the same sale.

Will a postback let me track sales from a mobile app?

Yes — that's one of its biggest strengths. Apps often have no web confirmation page for a pixel to load on, so a server-side postback is usually the only reliable way to report app conversions to Rakuten.

What happens if my server fails to send a postback?

The sale simply won't appear in Rakuten and the affiliate won't be credited. That's why you should log every attempt and build a retry queue, so a momentary network blip doesn't quietly cost an affiliate their commission.

Need help with your programme?

Get personalised, expert advice on your affiliate setup — completely free.

Get your free audit →