/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.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.apikey:secret eller secret:).
Angiv BASE som organisationens regionale vært – se
Regioner.
Gennemløb af en liste
IndlæsLIVING_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 ettype-filter på side to – returneres en 400 med koden
invalid_request på parameteren page_token:
400 Invalid request
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. Ved429 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.
