Integration modes: server-side (API) vs client-side (ads.js)

Modified on Mon, 17 Aug at 11:06 PM

All heavy logic — the LLM call, intent detection, catalog matching, click tokens, rate limits — runs on the Indoleads side. Your app only passes us the conversation and renders the card.


one conversation turn
User → [your app] → HTTPS → [Indoleads AI Ads API] → LLM
          ↑                            │
          └──────── reply + ad (card) ─┘

card click (Indoleads domain, not yours)
User → GET /c/{token} → 302 → network tracking link → advertiser

	Mode A — server-side (recommended)	Mode B — client-side
How	Your backend calls `POST /api/chat`, gets JSON, renders the card in your UI	Our `ads.js` is loaded on the page; calls run from the browser via `IndoleadsAds.chat()` / `renderAd()`
Key	Stays on your server, in secrets	Public per-domain key; domains whitelisted
Control	Full — you decide when/how to show	Less — but fastest to ship
CSP	`connect-src` API domain, `img-src` merchant CDNs	+ `script-src` ads.js domain
Best for	Products with their own backend/LLM pipeline	Static sites, widgets, quick pilots

In both modes the response is the same object — reply (always show it) + ad (object or null) + intent — see API contract. In both modes the click must go only through our /c/{token} link.

Server requirements for Mode A: any language with outbound HTTP+JSON, UTF-8, outbound HTTPS 443, TLS 1.2+ — see Requirements.