---
url: https://docs.dataflair.ai/dataflair/toplist-api/integration-model.md
description: >-
  Fetch toplists ahead of time and resolve the visitor geo locally at render
  time.
---

# 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](/dataflair/toplist-api/toplists-endpoint)) 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](/dataflair/toplist-api/geo-targeting) 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](/dataflair/toplist-api/reference-implementations)).