How AffilFinder works
AffilFinder connects publishers who have geo-restricted audiences with advertisers who pay per click to reach those visitors. The product has three public surfaces you should know about: the publisher app (where you configure sites and keys), the embeddable scripts (what runs on your pages), and the public HTTP API that powers decisions, offers, and measurement.
The roles
| Role | What they do |
|---|---|
| Publisher | Owns websites, defines where their product is legally available (geo rules), and embeds the AffilFinder script. |
| Advertiser | Funds a balance, creates CPC offers, and pays when eligible visitors click through to their landing pages. |
| AffilFinder | Matches offers to traffic, enforces geo and quality rules, tracks impressions and clicks, and moves money according to your contract. |
You can be a publisher, an advertiser, or both from the same organization in the app.
End-to-end flow (browser)
1. A visitor opens a page on your site. Your page loads the AffilFinder script from our CDN (or a compatible proxy you configure for local development).
2. The script asks the decision service whether this visitor should see your normal experience or the monetization path. That decision uses the visitor’s location together with the geo allowlist you configured for that website.
3. If the visitor is allowed, nothing else is shown by AffilFinder — they use your site as usual.
4. If the visitor is on the monetization path, the script requests eligible offers for that page view. Offers are ranked and displayed either as a full-screen experience or inside a container you provide, depending on your display mode.
5. When offers appear, the script records impressions. If the visitor clicks an offer, we record a click and send them through a short redirect URL that attributes the visit to the right publisher, website, and offer before landing on the advertiser’s page.
Throughout this flow, requests from the browser are tied to the public key and website key you were given in the dashboard. Your registered domain must match the site making the request so only your properties can use your keys.
Soft-decline (optional)
Some teams want to show alternative offers only after your own eligibility or risk checks fail — for example after a signup form is rejected. For that workflow you enable the optional decline widget in the dashboard, load a second script, and open a short-lived session from the browser. Only your servers may complete that session using an integration secret; the secret never belongs in front-end code.
Funding and earnings (conceptual)
- Advertisers add funds (for example by card or supported crypto) and set CPCs and budgets per offer.
- When a click is counted under our quality rules, the CPC is applied against the advertiser’s balance and publisher earnings are recorded for reporting and payouts.
Exact rates, holds, and payout schedules are defined in your agreement and in the in-product billing screens.
Where to go next
- REST API reference — public endpoints, parameters, and response shapes.
- Widget integration reference — scripts, attributes, and behaviors.
- Widget installation — copy-paste snippets for your stack.
Need more help?
Can't find what you're looking for? Reach out to our team and we'll get you sorted.