DEV Community: Feedico

How to get commission rates from 7 affiliate networks with one API

Feedico — Sat, 17 Oct 2026 13:43:35 +0000

If you have ever built a coupon site, a cashback app or a browser extension, you know the first two weeks go to plumbing, not product. Every affiliate network has its own API:

CJ mixes GraphQL and XML endpoints.
Awin is REST, with a rate limit of about 20 calls a minute.
Impact is paginated REST, with terms stored per campaign contract.
TradeTracker is SOAP.
Admitad writes commission rates as strings like "5.60%, 210.00-280.00USD".

And before any of that, you have to apply to each network and to each merchant programme, then wait for approvals.

This post shows a shortcut: one affiliate API that already normalizes seven networks, returns the commission rate for every store, and gives you tracked links you can publish today. I work on it, so take the enthusiasm with a grain of salt; the code is real and you can run it with a free token.

What we'll build

A small Node script that:

Finds stores that ship to France and allow cashback traffic.
Prints what you would earn per sale at each store.
Builds a tracked link that remembers which of your users clicked it.
Receives a signed webhook when that user's purchase is approved.

1. Get a token

Create a free account on the Feedico Partner Program, verify your site or app, and create an API token in Settings. Tokens start with fdcp_. Keep it on your server.

You don't need your own CJ, Awin or Impact account: the links run on Feedico's network accounts, and you keep 65% of each commission.

2. Find stores and their commission rates

// node >= 18
const res = await fetch("https://partner.feedico.io/api/catalog/merchants", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.FEEDICO_TOKEN}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ countries: ["FR"], cashback: "allowed", pageSize: 5 }),
});
const { merchants, meta } = await res.json();

const pct = (r) => (r.min === r.max ? `${r.min}%` : `${r.min}–${r.max}%`);
console.log(`${meta.total} stores`);
for (const m of merchants) {
  const rate = m.commission?.partnerRate;
  console.log(m.name, rate ? `you earn ${pct(rate)}` : "rate not published", m.goUrl);
}

Output (October 2026):

9 stores
Harfington Many GEOs  you earn 4.55%       https://feedico.io/go/37060?p=…
Gshopper Many GEOs    you earn 2.6%        https://feedico.io/go/24073?p=…
Redmagic WW           you earn 1.1%        https://feedico.io/go/20543?p=…
Italiarail [CPS]      rate not published   https://feedico.io/go/21754?p=…
Alibaba WW            you earn 1.37–3.64%  https://feedico.io/go/20881?p=…

A few things are happening here:

countries: ["FR"] returns stores targeting France, plus worldwide ones.
cashback: "allowed" keeps only stores whose programme explicitly allows cashback traffic. Most networks don't publish this rule, which is why the French list is short today; every store also carries cashbackAllowed: "yes" | "limited" | "no" | "unknown".
commission is the part that usually takes the longest to build. Each network reports rates differently, and here they come back in one shape (example values):

"commission": {
  "model": "percent",
  "rate": { "min": 7, "max": 7 },
  "partnerRate": { "min": 4.55, "max": 4.55 },
  "cookieDays": 30,
  "validationDays": 44,
  "policies": { "cashback": "allowed", "couponSites": "allowed" }
}

rate is what the network pays; partnerRate is your share. When a network doesn't publish a rate, the value is null, not a guess.

3. Track which of your users clicked

Add your own user id to the link with sub:

const link = new URL(merchant.goUrl);
link.searchParams.set("sub", "member_48213"); // an id from your database, never an e-mail
// https://feedico.io/go/37060?p=…&sub=member_48213

The sub is stored with the click on Feedico's side and never sent to the store. It comes back in the reports (GET /api/reports/commissions?sub=member_48213) and in webhooks.

4. Get a signed webhook when a sale is approved

Save an HTTPS URL in your partner settings. Every time a click earns a commission, and again when the commission is approved, declined or paid, you get a POST like this:

{
  "id": "evt_1842",
  "type": "commission.approved",
  "data": {
    "commissionId": 912,
    "sub": "member_48213",
    "status": "approved",
    "previousStatus": "pending",
    "amount": 3.25,
    "currency": "EUR"
  }
}

Verify the signature before you trust it. The header is X-Feedico-Signature: t=<unix time>,v1=<hex>, an HMAC-SHA256 of <t>.<raw body>:

import crypto from "node:crypto";

function verify(rawBody, header, secret) {
  const p = Object.fromEntries(header.split(",").map((kv) => kv.split("=")));
  if (Math.abs(Date.now() / 1000 - Number(p.t)) > 300) return false; // reject replays
  const want = crypto.createHmac("sha256", secret).update(`${p.t}.${rawBody}`).digest();
  const got = Buffer.from(p.v1 || "", "hex");
  return got.length === want.length && crypto.timingSafeEqual(got, want);
}

For a cashback app, the flow is: credit pending cashback on commission.pending, make it available on commission.approved, reverse it on commission.declined. Merchants can cancel sales during their validation period (validationDays above), so don't pay out earlier.

What this doesn't do

To be fair to the alternatives:

It covers 7 networks, not hundreds. If you already have accounts on many networks and just want one report of your own sales, a reporting aggregator such as Strackr, wecantrack or Affluent fits better.
Cashback rules are only as good as what networks publish. Admitad and TradeTracker report them per programme; the others mostly don't, so those stores show unknown until the network confirms.
Coupons come from network feeds and are not checkout-tested.

I wrote a longer, dated comparison here: Best affiliate APIs in 2026.

How I Normalized 74,000+ Scattered Coupon Feeds into a Single Real-Time API (And Built a Live Sandbox)

Feedico — Fri, 12 Jun 2026 07:52:33 +0000

Hey fellow devs,

If you’ve ever dealt with affiliate networks like CJ, Awin, or Impact, you already know the pain. Each network speaks a completely different language. One gives you data in a bloated XML format, another uses a weirdly nested JSON structure, and the third one updates its endpoints whenever it feels like it.

A few months ago, I got sick of writing separate custom parsers for every single network just to keep a coupon directory updated.

So, I decided to build a unified middleware that does the heavy lifting: aggregating, parsing, de-duplicating, and normalizing tens of thousands of affiliate data points into a single, blazing-fast API.

Today, I finally rolled out the live playground for it, and I wanted to share the architecture under the hood and how it works.

The Problem: The "Affiliate Spaghetti Data"
When you pull merchant vouchers globally, you face massive inconsistency:

brand_id vs merchant_name: Network A calls it "Merchant XY", Network B calls it "Merchant XY LLC".

Expiry Dates: Some networks use Unix timestamps, some use YYYY-MM-DD, and others just leave it null for ongoing deals.

Tracking Links: Appending custom click parameters (subID or sid) without breaking the redirect chain is a nightmare.

If your database can't handle this normalization dynamically, your frontend will either render broken links or stale data.

The Architecture: How It Works
I wanted the engine to be ridiculously fast. We currently track 41,452 unique merchants and over 74,296 active coupon codes.

Here is the high-level flow of the engine:

The Ingestion Layer: A fleet of cron jobs (Node.js/TypeScript) fetches raw data from master affiliate APIs at staggered intervals to prevent rate-limiting.

The Normalization Pipeline: Every raw coupon object passes through a strict validation schema. Names are slugified, dates are unified to a standard ISO format, and expired tokens are instantly flagged.

The Storage Strategy: Instead of blasting heavy relational JOIN queries every time a user types a word, everything is indexed efficiently so it handles full-text search instantly.

The Frontend Challenge: Making It Look Like an API Dashboard
I didn't want to build just another generic "coupon site" that looks like a spam factory from 2010. Since this is a B2B SaaS platform for developers and publishers, the UI needed to feel like a Live Sandbox.

I spent the last few days cooking the frontend. It uses Server-Side Rendering (SSR) for the initial payload so search engine bots don't just see a blank loading spinner, but the search itself is fully reactive.

When you type a keyword or a brand name (e.g., "travelup" or "hosting"), it instantly filters through the dataset with a 300ms debounce, updating the browser URL on the fly without refreshing the page.

Here is a quick look at what the dashboard looks like right now:

TypeScript
// A sneak peek into how the omni-search handles both brand and content filtering

const filterCoupons = (query: string, dataset: Coupon[]) => {
  const cleanQuery = query.toLowerCase().trim();
  if (!cleanQuery) return dataset.slice(0, 20); // Default fallback

  return dataset.filter(item => 
    item.brand_name.toLowerCase().includes(cleanQuery) || 
    item.coupon_description.toLowerCase().includes(cleanQuery)
  );
};

Check Out the Live Sandbox
The project is called Feedico, and the live sandbox is officially up and running.

You can break it, search for random brands, test the response speeds, or download sample raw CSV/XML exports directly from the UI:https://feedico.io/live-coupon-feed

Feedico Live Coupon Feed & Sandbox

If you want to see a specific query example in action (like how it renders pre-filtered data via SSR), check out this live endpoint instance:

What’s Next?
I'm planning to open up the public API documentation next week so developers can just fetch clean, raw JSON streams by brand or keyword without scraping anything manually.

I’d love to get some brutal feedback from the Dev.to community:

How's the initial page load speed for you?

Would you prefer Webhooks over standard REST polling for real-time coupon updates?

Let me know in the comments below! Appreciate you guys reading.