Integration model: fetch ahead, resolve locally

DataFlair does not offer a live, per-request "give me the right toplist for this visitor" endpoint. Instead:

1. You call GET /api/v1/toplists (optionally scoped to one template, see Toplists endpoints) on your own schedule, e.g. a periodic background sync job, not on the critical path of a real visitor request.
2. You store what comes back in your own application (database, cache, wherever fits your stack).
3. At the moment you actually render a toplist to a real visitor, your own code detects that visitor's country and decides, against your already-fetched data, whether and what to show. See Geo-targeting & compliance for the exact algorithm to run at this step.

Nothing in step 3 calls back to DataFlair. This is a deliberate architectural choice, not a missing feature: it keeps DataFlair off your rendering hot path, and it's the same pattern DataFlair's own WordPress plugin uses (sync in the background, resolve geo locally at render time against already-synced data, see Reference implementations).