Coherta made in Denmark
Få en demo

Support Universe

Hvad er API pagination (offset, cursor, keyset)?

API pagination er den metode, et API bruger til at returnere store datasæt i mindre “sider”, så du kan hente resultater stabilt og effektivt. De mest udbredte tilgange er offset-baseret pagination, cursor-baseret pagination og keyset pagination, som hver især påvirker ydeevne, datakonsistens og robusthed ved integrationer.

Hvad består API pagination (offset, cursor, keyset) af?

Uanset model består pagination typisk af tre faste byggesten:

  • Page size (limit): Hvor mange records du får pr. kald (fx 50, 100 eller 500).
  • Position/markør: Hvordan API’et ved, hvor i datasættet du er nået til (offset, cursor eller “sidste set”-nøgle).
  • Metadata og kontrolfelter: Oplysninger der hjælper klienten videre, fx next_cursor, has_more, total (nogle gange), eller links til næste side.

De tre pagination-typer adskiller sig primært ved, hvordan “positionen” udtrykkes:

  • Offset pagination: “Spring N rækker over og returnér næste limit rækker.”
  • Cursor pagination: “Fortsæt fra en opaque markør, som API’et udsteder.”
  • Keyset pagination: “Fortsæt ud fra en sorteringsnøgle (fx created_at + id) og hent næste blok.”

Hvordan fungerer API pagination (offset, cursor, keyset)?

Offset pagination: nemt, men skrøbeligt ved ændringer

Offset er den klassiske model, hvor du sender fx offset=200&limit=50. API’et returnerer rækker 201–250 i en bestemt sortering. Det er let at implementere og let at forstå, men der er to typiske problemer i praksis:

  • Ydeevne: Store offsets kan blive langsomme i databasen, fordi den skal “gå forbi” mange rækker, før den kan levere dine 50.
  • Inkonsistens: Hvis der indsættes eller slettes data mellem dine kald, kan du få dubletter eller miste records, fordi “række nr. 201” ikke længere er den samme.

Cursor pagination: robust og skalerbart til streams og store lister

Cursor pagination bruger en markør, som API’et genererer og returnerer i svaret (fx next_cursor). Næste kald sender du cursoren tilbage: cursor=abc123&limit=50. Markøren er ofte “opaque” (du kan ikke aflæse den), og den repræsenterer en position i en stabil sortering.

Fordelen er, at API’et kan optimere opslaget, og du undgår typisk store offset-scan. Desuden er cursor pagination ofte mere robust, når datasættet ændrer sig undervejs, fordi cursoren refererer til en kendt position frem for et indeks.

Keyset pagination: cursor-princippet med gennemsigtige nøgler

Keyset pagination (også kaldet “seek pagination”) er nært beslægtet med cursor, men i stedet for en opaque cursor bruger du typisk den sidste records sorteringsnøgle(r) fra forrige side. Eksempel: sortér på created_at og id (for at undgå ties). Næste side hentes med en betingelse som “hent records hvor (created_at, id) er større end (sidste_created_at, sidste_id)”.

Det giver god performance og stabil fremdrift, men kræver, at API’et (og dit forbrug) er disciplineret omkring sortering og unikke nøgler.

Hvorfor er API pagination (offset, cursor, keyset) vigtigt for B2B-virksomheder?

Pagination lyder teknisk, men den har direkte betydning for din go-to-market og din datafundament:

  • Stabile lead-flows: Når du henter leads, konti eller firmadata i store mængder, er robust pagination afgørende for ikke at miste eller duplikere records. Det påvirker alt fra pipeline-rapportering til segmentering.
  • Lavere integrationsomkostninger: Jo færre fejl, retries og “mystiske huller” i data, desto mindre tid bruger dit team på fejlsøgning.
  • Bedre time-to-value: En pagination-model, der skalerer, gør det muligt at automatisere import/eksport og berigelse uden at ramme performancevægge.
  • Datakvalitet i marketing automation og CRM: Dubletter og manglende records kan give forkerte audiences, forkert scoring og upræcis attribution.

Hvis du arbejder med leadgenerering og firmadata, er pagination en af de “usynlige” beslutninger, der afgør, om din dataproces er driftssikker. Hvis du vil forstå, hvordan en leadmotor typisk leverer data til salgs- og marketingflows, kan du se, hvordan Coherta fungerer.

Hvordan bruges API pagination (offset, cursor, keyset) i praksis?

I praksis handler pagination ikke kun om at “bladre”. Det handler om at designe en hentelogik, der kan køre automatisk, tåle fejl og være konsistent over tid.

Vælg model ud fra din use case

  • Offset passer til små, statiske lister og simple backoffice-views (fx “vis side 3” i en UI), hvor nøjagtig side-navigation betyder mere end stabil data-udlæsning.
  • Cursor passer til store datasæt, løbende synkroniseringer og endpoints, hvor data ændrer sig ofte.
  • Keyset passer til “infinite scroll”, batch-processing, eksport og synkronisering, hvor du har en naturlig sortering (fx tid eller ID) og vil undgå performance-problemer.

Design en sikker henteproces (uanset model)

Hvis du fx bygger en integration til CRM eller marketing automation, bør du typisk:

  • Fastlæg en page size der matcher API’ets rate limits og dit systems kapacitet.
  • Gem din state (offset/cursor/last_key) efter hver succesfuld side, så du kan fortsætte ved fejl.
  • Implementér retries med backoff ved midlertidige fejl (429/5xx).
  • Dedup i din modtager (idempotent write), så dubletter ikke skaber rod, hvis du må genkøre batchen.
  • Brug stabil sortering (fx created_at + id) og undgå sortering på felter, der kan ændre sig.

Pagination i lead- og firmadataflows

Når du arbejder med B2B leadgenerering, er pagination typisk en del af en større proces: filtrér efter ICP, hent data i batches, berig/valider og send videre til dine systemer. Hvis du vil sikre, at du henter “de rigtige” virksomheder først, giver det mening at starte med en skarp ideel kundeprofil, så du ikke spilder API-kald på irrelevante segmenter.

Hvis du fx skal have data ind i marketing automation, handler det ikke kun om at hente alt, men at hente det stabilt og i et format, der passer til dit workflow. Du kan fx se, hvordan leads kan aktiveres i et konkret flow med leads til ActiveCampaign.

Til større udtræk (fx segmenteksport til BI eller kampagneværktøjer) er det vigtigt at vælge en pagination-model, der ikke degraderer ved store datamængder. I praksis bør eksportflows altid være designet til at kunne genoptages, hvilket også spiller sammen med dine procedurer for eksport og datahåndtering.

Fordele og ulemper

  • Offset: Fordel: enkelt og intuitivt. Ulempe: dårligere performance ved store offsets og risiko for huller/dubletter ved ændringer i datasættet.
  • Cursor: Fordel: skalerbar og ofte mere konsistent ved ændringer. Ulempe: svært at “hoppe til side 10”, og cursoren kan være tidsbegrænset afhængigt af API-design.
  • Keyset: Fordel: hurtig og stabil ved store mængder. Ulempe: kræver gennemtænkt sortering og håndtering af ties (typisk med en sekundær nøgle som id).

Typiske misforståelser

  • “Offset er altid fint, hvis vi bare sætter limit lavt.” Limit påvirker mængden pr. side, men store offsets kan stadig koste meget, fordi databasen ofte skal scanne mange rækker for at nå frem til din startposition.
  • “Cursor og keyset er det samme.” De minder om hinanden, men cursor er ofte opaque og API-styret, mens keyset typisk bruger eksplicitte sorteringsnøgler, som du selv kan se og gemme.
  • “Pagination sikrer, at vi aldrig får dubletter.” Pagination alene er ikke en garanti. Hvis du genkører en side efter en timeout, eller hvis data ændrer sig, kan dubletter opstå. Løsningen er idempotente writes og dedup baseret på stabile IDs.
  • “Vi kan bare sortere på ‘updated_at’ og paginere derfra.” Hvis et felt kan ændre sig, kan rækkefølgen ændre sig midt i din gennemløb. Brug hellere en stabil sortering, eller håndtér incremental sync med tydelige vandmærker og klare regler.

FAQ 

Hvilken pagination-type bør du vælge til en dataeksport med mange rækker?

Til store eksporter er cursor eller keyset typisk bedst, fordi de skalerer bedre og reducerer risikoen for performance-problemer. Offset kan fungere ved mindre mængder, men bliver ofte tungt, når du når høje offsets.

Hvordan undgår du at miste records, når data ændrer sig under pagination?

Brug en stabil sortering (fx created_at + id) og en model som cursor/keyset. Kombinér med idempotent indlæsning (opsert) i dit modtagersystem, så dubletter ikke skaber fejl, hvis du må genkøre.

Kan du “hoppe” til en vilkårlig side med cursor pagination?

Som udgangspunkt nej. Cursor er designet til sekventiel gennemløb. Hvis du har behov for random access (“side 12”), er offset mere naturligt, men du betaler ofte med lavere konsistens og performance.

Hvad er en god page size (limit) i B2B integrationer?

Det afhænger af rate limits og payload-størrelse, men mange integrationer starter med 50–500 pr. kald. Vælg en størrelse, der giver færre kald, uden at hvert kald bliver så stort, at det timeouter eller rammer grænser for responstid.

Hvordan hænger pagination sammen med API rate limiting?

Pagination øger typisk antallet af kald. Derfor bør du kombinere pagination med caching, batching, backoff-retries og en strategi for at genoptage jobs, så du ikke starter forfra ved midlertidige fejl eller 429-responser.

Få pagination til at spille sammen med din leadmotor og dine integrationer

Hvis du vil bruge firmadata og leads operationelt, skal din pagination-strategi være lige så robust som din målretning og dine workflows. Coherta kan hjælpe dig med at strukturere dataflows fra søgning og udvælgelse til aktivering i dine systemer. Læs mere om vores leadmotor, og hvis du allerede planlægger integration, kan du bruge Cohertas API som udgangspunkt for en stabil synkronisering.