Engineering · Schema normalization
How Feedico normalizes affiliate network schemas
Updated June 22, 2026 · ~16 min read
CJ, Awin, and Impact were built in different eras — different auth headers, pagination models, and JSON field names for the same commercial concept: a merchant programme and its promotions.Feedico sits between those upstream APIs and your product, mapping each network into one firm row and one coupon row contract. This page explains the mapping table, provider tags, deduplication keys, pagination normalization, and how ids stay stable when advertisers churn offers overnight.
Normalization pipeline (conceptual)
Upstream sync jobs pull advertiser programmes and promotions using credentials you store in the dashboard. Each integration adapter extracts merchant keys, coupon ids, codes, titles, date windows, and tracking URLs, then writes into tenant-scoped tables. Customer list APIs read those tables and emit the normalized JSON your apps consume — you never parse CJ link XML, Awin voucher JSON, or Impact Actions payloads in frontend code.
For cross-network planning read CJ vs Awin vs Impact API; for product positioning read the unified affiliate API pillar. This article is the field mechanics between those pages.
Provider tags
Every normalized row includes a provider string. Filters on POST /api/v1/me/coupons and /me/networks accept this slug. Responses also return availableProviders for the connected account.
| Network | Feedico provider tag | Typical externalMerchantKey source |
|---|---|---|
| CJ Affiliate | cj_affiliate | Advertiser / link programme id |
| Awin | awin_affiliate | Programme id (snapshot or unified row) |
| Impact | impact_com | Campaign or brand id from Actions catalog |
Firm (merchant / programme) field mapping
Firms represent advertisers or programmes you are approved to promote. The normalized network object powers merchant pickers, eligibility checks, and coupon count badges.
| Feedico field | CJ (conceptual) | Awin (conceptual) | Impact (conceptual) |
|---|---|---|---|
| displayName | advertiserName | programme.name / merchant.name | CampaignName / BrandName |
| externalMerchantKey | advertiserId / cid | programmeId | CampaignId / BrandId |
| merchantWebsiteUrl | programURL / website | displayUrl / merchant.url | LandingPage / website |
| status | relationshipStatus | membershipStatus | ContractStatus / State |
| lastSyncedAt | (sync timestamp) | (sync timestamp) | (sync timestamp) |
| couponCount | (derived count) | (promotion snapshots) | (Actions with codes) |
Awin programme rows may surface with ids prefixed awin_snap_ when served from entity snapshots; unified integrations use numeric ids tied to app_user_affiliate_networks. Your warehouse should key on provider + externalMerchantKey, not displayName alone.
Coupon field mapping
Coupons unify coded promos, percentage-off titles, and tracked link offers. Upstream-only metadata (voucher type, regional flags, native status enums) is preserved under extra.
| Feedico field | CJ (conceptual) | Awin (conceptual) | Impact (conceptual) |
|---|---|---|---|
| externalCouponId | linkId / promotionId | promotionId / voucher.id | DealId / PromoCodeId |
| code | couponCode | voucher.code | PromoCode / Code |
| title | linkName / description | title / description | DealName / Name |
| offerUrl | clickUrl / destination | url / deeplink | TrackingLink / LandingPage |
| startsAt | promotionStartDate | startDate | StartDate |
| endsAt | promotionEndDate | endDate / expiryDate | EndDate |
| networkName | advertiserName | programme.name | CampaignName |
| fetchedAt | (sync pass time) | (sync pass time) | (sync pass time) |
{
"id": "1849201",
"networkId": "88341",
"networkName": "Example Retailer EU",
"provider": "awin_affiliate",
"externalMerchantKey": "12345",
"externalCouponId": "promo-998877",
"code": "SPRING15",
"title": "15% off sitewide",
"description": "Excludes gift cards.",
"startsAt": "2026-03-01T00:00:00.000Z",
"endsAt": "2026-06-30T23:59:59.000Z",
"offerUrl": "https://…/tracked-offer",
"fetchedAt": "2026-06-20T14:22:11.000Z",
"status": "active",
"extra": { /* upstream-native fields preserved */ }
}Dedup strategy
Feedico deduplicates at sync time and exposes stable keys for your warehouse upserts:
- Firms: composite
(provider, externalMerchantKey) - Coupons: composite
(provider, externalCouponId)scoped to the tenant and property - Lifecycle: rows absent from the latest feed pass receive
status: inactiveinstead of hard deletion — downstream mirrors can soft-delete or archive - Global catalogue (separate product surface) deduplicates coded promos across tenants for discovery — different trust model from
/me/*rows that include yourofferUrl
Pagination normalization
Native APIs diverge: offset/limit, page cursors, link headers, SOAP paging. Feedico customer list endpoints normalize to one pattern:
| Request (POST JSON) | Response |
|---|---|
| page (1-based) | page echoed |
| pageSize (max 200) | pageSize echoed |
| provider, firmName filters | recordCount total for query |
| includeInactive (optional) | data[] array of normalized rows |
ETL workers loop until page * pageSize >= recordCount. See the coupon warehouse ETL guide for a reference worker.
Id stability
Three identifiers matter for production integrations:
- Feedico id — internal numeric string stable for the life of the row in your account (useful for editorial overrides in WordPress or CMS foreign keys).
- externalMerchantKey / externalCouponId — upstream identity for warehouse primary keys and cross-environment parity.
- networkId — joins coupons to firm rows; stable while the programme remains connected.
When advertisers rename campaigns, display fields may change while external keys remain constant — upsert on external keys, not titles. When upstream reissues a promotion under a new id, you will see a new row; expired predecessors flip to inactive.
The extra JSON escape hatch
Not every network field belongs in the top-level contract — regional voucher types, CJ link categories, Impact deal categories, compliance flags. These land in extra verbatim (parsed JSON). Early warehouse iterations should store raw_json alongside normalized columns so product can promote fields into first-class columns without re-syncing history.
Warehouse and webhook implications
Normalization in Feedico means your ETL maps one JSON shape into SQL — not three adapter modules. Pair scheduled pulls with webhook delta sync when eligible plans expose affiliate.delta events. Compare coded coupon velocity on the live data report if you need external benchmarks.
Frequently asked questions
- What is a normalized affiliate row in Feedico?
- A firm (merchant/programme) or coupon object with stable camelCase fields — provider, externalMerchantKey, externalCouponId, code, title, offerUrl, startsAt, endsAt, fetchedAt — regardless of whether the upstream source was CJ, Awin, or Impact. Network-native field names live in extra JSON when you need them.
- Why not key coupons only on promo code strings?
- The same code can appear for different merchants, expire and return with a new upstream id, or exist as link-only offers without codes. Feedico deduplicates on provider plus externalCouponId (and firms on provider plus externalMerchantKey).
- How do provider tags work?
- Every row carries a provider slug such as cj_affiliate, awin_affiliate, or impact_com. List endpoints accept an optional provider filter; responses include availableProviders so your UI can render source badges and compliance disclosures.
- Are Feedico ids stable across sync runs?
- Yes for rows that remain in your catalogue: internal numeric ids persist in the database while externalMerchantKey and externalCouponId track upstream identity. Rows missing from the latest sync pass are marked inactive rather than deleted, so your warehouse can soft-delete or archive.
- How does pagination differ from native network APIs?
- Customer list endpoints use POST JSON with page, pageSize (max 200), and recordCount totals — the same contract for /me/coupons and /me/networks. You do not reimplement CJ link pagination, Awin voucher offsets, or Impact cursor quirks in application code.
- Where should I read cross-network comparisons?
- Start with CJ vs Awin vs Impact API for auth and operational quirks, then the unified affiliate API pillar for product framing. This page is the field-mapping mechanics layer between those guides.
You need programme approval and compliant use at each affiliate network. Feedico provides the integration layer - not a substitute for network terms.