Skip to main content
Alle listeendepunkter i /v1 returnerer den samme konvolutten og paginerer på samme måte: tokenbasert og kun forover.

Listekonvolutten

string
Alltid "list".
array
Siden med ressurser, i en stabil og deterministisk rekkefølge.
string | null
Send denne verdien som page_token i den neste forespørselen for å hente neste side. null når det ikke finnes flere resultater.
boolean
Angir om det finnes flere resultater utover denne siden.

Forespørselsparametere

integer
standard:"25"
Sidestørrelse. Et heltall mellom 1 og 500. Verdier utenfor dette området gir en 400 med koden invalid_request.
string
next_page_token fra det forrige svaret. Utelat den for den første siden.
Det finnes ingen offset-parametere, ingen navigering til forrige side og ingen eksakte totalantall. Hvis du vil telle en samling, må du gå gjennom den.
Unntak: GET /v1/cohorts/{id}/members returnerer maksimalt 50 rader per side, selv om du ber om en høyere limit. has_more og next_page_token gjenspeiler fortsatt det faktiske restantallet i kohorten.
Autentiser med en av de to Basic-legitimasjonsformene – se hurtigstart (apikey:secret eller secret:). Sett BASE til organisasjonens regionale vert – se regioner.

Gå gjennom en liste

Last inn LIVING_SECURITY_API_KEY fra hemmelighetsbehandleren din, som i hurtigstarten. Dette eksemplet krever entity:read; nøkkelen som ble brukt i veiledningen for den første forespørselen, kan trenge denne ekstra tilgangen. Installer requests for Python eller jq for skalleksemplet. Begge eksemplene låser en versjon, holder filtrene uendret og avviser omdirigeringer. De stopper ved feil og etter 1 000 sider i stedet for å rapportere en delvis gjennomgang som fullført. Pythons lesetidsavbrudd begrenser inaktivitet, ikke den totale varigheten til jobben; angi en tidsfrist for jobben i integrasjonen din. Be om sider til next_page_token er null. Foretrekk limit=500 for bulkavlesing, slik at du dekker samlingen med færre forespørsler – se grenser for forespørselsrate.

Hold filtrene stabile under paginering

Sidetokener er ugjennomsiktige, signerte pekere. Hvert token er bundet til organisasjonen, den autentiserte tjenestekontoen, kontraktsversjonen og det eksakte filtersettet i forespørselen som produserte det. Hvis du endrer noe av dette midt i en gjennomgang – for eksempel ved å legge til et type-filter på side to – returneres en 400 med koden invalid_request for parameteren page_token:
400 Invalid request
Hvis du vil endre filtre, må du starte en ny gjennomgang fra den første siden.
Behandle page_token som en ugjennomsiktig streng: send den tilbake nøyaktig slik du mottok den. Ikke dekod, lagre langsiktig eller konstruer tokener – det interne formatet kan endres når som helst uten varsel.
Listeendepunkter avviser spørringsparametere de ikke støtter, med en 400 invalid_request som angir parameteren. Se referansen for hvert endepunkt for å finne hvilke filtre som støttes.

Håndter en avbrutt eller skiftende samling

Disse eksemplene forsøker ikke automatisk på nytt ved feil. For 429 må du følge Retry-After og den avgrensede veiledningen for nye forsøk. Bruk samme region, tjenestekonto, versjon, filtre og sist vellykket behandlede sidetoken når du prøver en lesing på nytt. Bytte av legitimasjon gir ikke tilgang: hver forespørsel kontrollerer fortsatt gjeldende tillatelser. En lesing over flere sider er ikke et øyeblikksbilde av samlingen. Rader kan endres mens du går gjennom den. Behandle ressurser ut fra den stabile id og gjør nedstrøms skriving idempotent; en omstart kan returnere en rad på nytt. Hvis et token avvises, undersøk feilen page_token og rett opp forespørselen før du starter på nytt fra side én. Ikke forkast tidligere behandlede data i det stille, og ikke marker en avbrutt eksport som fullført. For eksakte rapporteringstotaler bør du bruke den aktuelle rapporteringsressursen i stedet for å behandle en levende listegjennomgang som et øyeblikksbilde.