Skip to main content
Alle /v1 liste-endpoints returnerer den samme envelope og paginerer på samme måde: tokenbaseret og kun fremad.

Liste-envelope

string
Altid "list".
array
Siden med ressourcer i en stabil, deterministisk rækkefølge.
string | null
Angiv denne værdi som page_token i den næste anmodning for at hente den følgende side. null, når der ikke er flere resultater.
boolean
Angiver, om der findes flere resultater ud over denne side.

Anmodningsparametre

integer
standard:"25"
Sidestørrelse. Et heltal mellem 1 og 500. Værdier uden for dette interval returnerer en 400 med koden invalid_request.
string
next_page_token fra det forrige svar. Udelad den ved den første side.
Der er ingen offset-parametre, ingen gennemløb af forudgående sider og ingen eksakte totalantal. Hvis du vil tælle en samling, skal du gennemløbe den.
Undtagelse: GET /v1/cohorts/{id}/members returnerer højst 50 rækker pr. side, selv om du anmoder om en højere limit. has_more og next_page_token afspejler stadig den faktiske rest af kohorten.
Godkend med en af de to Basic-legitimationsformer – se Quickstart (apikey:secret eller secret:). Angiv BASE som organisationens regionale vært – se Regioner.

Gennemløb af en liste

Indlæs LIVING_SECURITY_API_KEY fra din hemmelighedsstyring som i quickstarten. Dette eksempel kræver entity:read. Nøglen, der blev brugt i vejledningen til den første anmodning, kan have brug for denne ekstra tilladelse. Installer requests til Python eller jq til shell-eksemplet. Begge eksempler fastlåser en version, bevarer filtre uændrede og afviser omdirigeringer. De stopper ved fejl og efter 1.000 sider i stedet for at rapportere et delvist gennemløb som fuldført. Pythons læsetimeout begrænser inaktivitet, ikke jobbets samlede varighed. Fastsæt en tidsfrist for jobbet i din integration. Anmod om sider, indtil next_page_token er null. Foretræk limit=500 til massehentning, så du dækker samlingen med færre anmodninger – se hastighedsbegrænsninger.

Hold filtre stabile under paginering

Sidetokens er uigennemsigtige, signerede cursorer. Hvert token er bundet til organisationen, den godkendte servicekonto, kontraktversionen og det præcise filtersæt i den anmodning, der frembragte det. Hvis du ændrer et af disse midt i gennemløbet – for eksempel ved at tilføje et type-filter på side to – returneres en 400 med koden invalid_request på parameteren page_token:
400 Invalid request
Hvis du vil ændre filtre, skal du starte et nyt gennemløb fra første side.
Behandl page_token som en uigennemsigtig streng: send den tilbage præcis som modtaget. Du må ikke afkode, gemme langsigtet eller konstruere tokens – deres interne format kan ændres når som helst uden varsel.
Liste-endpoints afviser forespørgselsparametre, de ikke understøtter, med en 400 invalid_request, der angiver parameteren. Se hvert endpoints reference for dets understøttede filtre.

Håndtering af en afbrudt eller skiftende samling

Disse eksempler forsøger ikke automatisk fejl igen. Ved 429 skal du overholde Retry-After og følge den begrænsede vejledning til genforsøg. Bevar samme region, servicekonto, version, filtre og det sidst behandlede sidetoken, når du forsøger en læsning igen. Skift af legitimationsoplysninger giver ikke adgang: hver anmodning kontrollerer stadig de aktuelle tilladelser. En læsning over flere sider er ikke et øjebliksbillede af samlingen. Rækker kan ændre sig, mens du gennemløber den. Behandl ressourcer ud fra deres stabile id, og gør efterfølgende skrivninger idempotente; en genstart kan returnere en række igen. Hvis et token afvises, skal du undersøge page_token-fejlen og rette anmodningen, før du starter forfra fra side ét. Kassér ikke stiltiende tidligere behandlede data, og markér ikke en afbrudt eksport som fuldført. Brug den relevante rapporteringsressource til eksakte rapporteringstotaler i stedet for at behandle et levende listegennemløb som et øjebliksbillede.