Feedico

← Home · Unified API · Product

Browser extensions

Instant coupon hints - without shipping secrets in the bundle

Extensions sit in a hostile environment: minified bundles, store review, and users who expect immediate hints. You need low latency and zero leaked secrets. The Coupon API stays on your server; the extension talks only to your thin API that returns already-scoped rows for the active retailer - backed by Feedico's normalized programme and coupon data across connected networks.

Who is this for?

When you are pitching a Chrome or Edge listing - or defending architecture in security review - the question is always “where do credentials live?”

Built for product teams shipping store-listed extensions - not prototypes that paste API keys into content.js.

Same multi-network coverage as your web stack

Sync coupon slices server-side from the providers your account is approved for - icons are vendor favicons for quick recognition; logo marks are trademarks of their owners.

CJ Affiliate favicon
CJ Affiliate
Awin favicon
Awin
Impact favicon
Impact
Admitad favicon
Admitad
TradeTracker favicon
TradeTracker
Partnerize favicon
Partnerize

Built for extension UX

Toolbar popups, omnibox badges, and checkout overlays need a tiny, stable payload - not raw network JSON. List and filter coupons on the server with Coupon API POST bodies; expose GET /hints?host=… (or equivalent) from your domain so reviewers see a clear data flow. Read provider in stored rows when disclosure asks where an offer originated.

Architecture at a glance

Networks → Feedico normalization → your datastore → thin hints API → extension. No bearer token in the shipped bundle.

  1. 1

    Sync from networks

    Background worker or cron pulls coupon slices via Feedico list endpoints into your DB or cache - same sources as your web product.

    PaginationPlan quotasWebhooks (eligible plans)
  2. 2

    Normalize & rank server-side

    One schema means one ranking pipeline: expiry, confidence, provider priority - no parallel parsers in the client.

    Firm + coupon keysDeduped merchantsTTL-friendly cache keys
  3. 3

    Your hints API

    Extension calls your origin with the active tab host or canonical URL; you authenticate the user, apply rate limits, return minimal JSON.

    Bearer only on serverPer-user throttlesAffiliate-safe redirect URLs
  4. 4

    Extension UI

    Render the best code, expiry, short disclosure, and tracking link you control - keep polling conservative; prefetch when the panel opens.

    Merchant-scoped cacheTab dedupeOptional prefetch

Why teams pick this pattern

  • Store-review friendly

    Credentials and Feedico tokens never ship in the extension package reviewers unpack.

  • Faster hint latency

    Serve from your edge or regional API; cache per merchant, not per tab storm.

  • One ranking model

    Same normalized rows as your site - no second set of network quirks in JS.

  • Attribution you own

    Outbound tracking URLs and disclosures stay on infrastructure you control.

  • Quota discipline

    Centralize API usage against your plan; backoff and upgrade in one place.

Performance & operations

Extensions amplify bad habits: a navigation listener that fires on every SPA route change will hammer your API. Model merchant-level TTL, reuse in-flight requests across tabs, and lean on server-side sync so the hot path is a cheap lookup - not a full network round trip. Where your plan allows, webhooks reduce how often you poll list endpoints to refresh slices; your hints endpoint still returns stale-while-revalidate friendly payloads for smooth UX.

Example hints payload (your API)

Illustrative JSON your backend might return after resolving the tab host to a merchant - field names are suggestions; align with your mobile or web clients. Under the hood, rows can map to normalized Feedico coupon fields (provider, code, expiresAt, etc.).

{
  "host": "shop.example",
  "merchant": "Example Shop",
  "bestOffer": {
    "title": "10% off orders",
    "code": "SAVE10",
    "expiresAt": "2026-06-01T23:59:59.000Z",
    "disclosure": "Affiliate savings; we may earn a commission.",
    "clickUrl": "https://your-tracker.example/r/…"
  }
}

Server-mediated hints vs fat client

At a glance: thin backend + Feedico vs fat extension
TopicRecommendedFat client / multi-API
Secrets in bundle✅ None - token on server❌ Keys extractable from JS
Coupon schema✅ One normalized model❌ N parsers & drift
Ranking logic✅ Single pipeline❌ Divergent per-network rules
Store review story✅ Clear data flow diagram❌ Opaque third-party calls
Operational load✅ Central quotas & logs❌ Client-side chaos

Deeper comparison: Feedico vs manual integrations.

Policy & disclosure

Store listings and regulators care how you explain data flows. Be explicit when savings are affiliate-driven; Feedico supplies metadata - not legal advice - so keep consent copy and network obligations aligned with each geography you ship in.

Why normalization matters now

Shopping assistants fail when every network needs a different parser and your extension ships five incompatible ranking heuristics. Publishers that “just” add another programme without a unified contract slow down shipping while debugging fragile clients. Feedico lets you keep network relationships and still expose one stable contract to your hints service - which is exactly what extension code wants.

Frequently asked questions

Should the extension call Feedico directly?
No. Extensions should call your backend, which holds the Feedico token and applies per-user limits. Never ship API keys in extension bundles or content scripts.
How do I match the active tab to a merchant?
Use your own domain-to-merchant mapping or normalized programme keys from Feedico listings you sync server-side; the extension sends the host or canonical URL to your service for lookup.
What about aggressive polling on every navigation?
That burns quota and annoys users. Cache results per merchant for a TTL, deduplicate tabs, and batch prefetch only when the user opts in or opens the panel.
Do I still need affiliate approval?
Yes. Feedico does not replace enrolment at each network. You connect credentials for programmes you are approved for; your extension UX must stay compliant with each network's terms and regional disclosure rules.

Related technical reads

Pair this use case with the contract reference on the Coupon API page and the unified affiliate API overview. Flagship network landings: CJ API, Awin API, Impact API.

You need programme approval and compliant use at each affiliate network. Feedico provides the integration layer - not a substitute for network terms.

Related pages

Comparisons & guides