Skip to main content
Varje /v1-listslutpunkt returnerar samma envelopp och paginerar på samma sätt: tokenbaserat och endast framåt.

Listenveloppen

string
Alltid "list".
array
Sidan med resurser, i en stabil och deterministisk ordning.
string | null
Skicka detta som page_token i nästa begäran för att hämta följande sida. null när det inte finns fler resultat.
boolean
Anger om det finns fler resultat utöver den här sidan.

Begäransparametrar

integer
standard:"25"
Sidstorlek. Ett heltal mellan 1 och 500. Värden utanför detta intervall ger 400 med koden invalid_request.
string
next_page_token från föregående svar. Utelämna den för den första sidan.
Det finns inga offsetparametrar, ingen bakåtnavigering mellan sidor och inga exakta totalantal. Om du vill räkna en samling måste du gå igenom den.
Undantag: GET /v1/cohorts/{id}/members returnerar högst 50 rader per sida, även om du begär ett högre limit. has_more och next_page_token återspeglar fortfarande den verkliga återstoden av kohorten.
Autentisera med någon av de två Basic-uppgiftsformerna – se Snabbstart (apikey:secret eller secret:). Ange BASE som organisationens regionala värd – se Regioner.

Gå igenom en lista

Läs in LIVING_SECURITY_API_KEY från din hemlighetshanterare på samma sätt som i snabbstarten. Det här exemplet kräver entity:read; nyckeln som användes i guiden för den första begäran kan behöva den ytterligare behörigheten. Installera requests för Python eller jq för shell-exemplet. Båda exemplen låser en version, behåller filtren oförändrade och avvisar omdirigeringar. De avbryts vid fel och efter 1 000 sidor i stället för att rapportera en ofullständig genomgång som slutförd. Pythons läs-timeout begränsar inaktivitet, inte den totala körtiden; ange en tidsgräns för hela jobbet i din integration. Begär sidor tills next_page_token är null. Föredra limit=500 för massläsning så att du täcker samlingen med färre begäranden – se hastighetsbegränsningar.

Håll filtren stabila under paginering

Sidtokens är ogenomskinliga, signerade markörer. Varje token är knuten till organisationen, det autentiserade tjänstekontot, kontraktsversionen och den exakta uppsättning filter som gällde för begäran som skapade den. Om du ändrar något av dessa under en genomgång – till exempel genom att lägga till ett type-filter på sida två – returneras ett 400 med koden invalid_request för parametern page_token:
400 Invalid request
Om du vill ändra filter startar du en ny genomgång från första sidan.
Behandla page_token som en ogenomskinlig sträng: skicka tillbaka den exakt som du fick den. Avkoda, lagra långsiktigt eller konstruera inte tokens – deras interna format kan ändras när som helst utan föregående meddelande.
Listslutpunkter avvisar frågeparametrar som de inte stöder med ett 400 invalid_request som anger parametern. Kontrollera varje slutpunkts referens för att se vilka filter som stöds.

Hantera en avbruten eller föränderlig samling

Dessa exempel försöker inte automatiskt igen vid fel. Vid 429, följ Retry-After och de begränsade riktlinjerna för omförsök. Behåll samma region, tjänstekonto, version, filter och senast framgångsrikt bearbetade sidtoken när du försöker en läsning igen. Att byta autentiseringsuppgifter ger inte åtkomst: varje begäran kontrollerar fortfarande aktuella behörigheter. En läsning över flera sidor är inte en ögonblicksbild av samlingen. Rader kan ändras medan du går igenom den. Bearbeta resurser utifrån deras stabila id och gör efterföljande skrivningar idempotenta; en omstart kan returnera en rad igen. Om en token avvisas, granska felet page_token och åtgärda begäran innan du startar om från första sidan. Kassera inte tyst tidigare bearbetade data och markera inte en avbruten export som slutförd. För exakta rapporteringstotaler ska du använda lämplig rapporteringsresurs i stället för att behandla en live-genomgång av en lista som en ögonblicksbild.