Skip to main content
Living Security के प्रत्येक /v1 list endpoint का envelope समान होता है और वे एक ही तरह से पेजिनेशन करते हैं: टोकन-आधारित और केवल आगे की दिशा में।

The list envelope

string
हमेशा "list"।
array
संसाधनों का पेज, एक स्थिर और निर्धारित क्रम में।
string | null
अगला पेज प्राप्त करने के लिए अगले अनुरोध में इसे page_token के रूप में पास करें। जब और परिणाम न हों, तो null।
boolean
क्या इस पेज के बाद भी और परिणाम उपलब्ध हैं।

Request parameters

integer
डिफ़ॉल्ट:"25"
पेज का आकार। 1 से 500 के बीच का पूर्णांक। इस सीमा से बाहर के मान कोड invalid_request के साथ 400 लौटाते हैं।
string
पिछले response से प्राप्त next_page_token। पहले पेज के लिए इसे छोड़ दें।
इसमें कोई offset पैरामीटर नहीं हैं, पिछले पेज पर जाने की सुविधा नहीं है, और कुल संख्या की सटीक गणना उपलब्ध नहीं है। किसी संग्रह की गणना करने के लिए उसे क्रमवार पूरा पढ़ें।
अपवाद: GET /v1/cohorts/{id}/members प्रति पेज अधिकतम 50 पंक्तियाँ लौटाता है, भले ही आप अधिक limit का अनुरोध करें। has_more और next_page_token फिर भी Cohort के वास्तविक शेष भाग को दर्शाते हैं।
किसी भी Basic credential रूप से प्रमाणीकृत करें — देखें Quickstart (apikey:secret या secret:)। BASE को संगठन के क्षेत्रीय होस्ट पर सेट करें — देखें Regions।

Walking a list

Quickstart की तरह अपने secret manager से LIVING_SECURITY_API_KEY लोड करें। इस उदाहरण के लिए entity:read आवश्यक है; पहले अनुरोध की मार्गदर्शिका में उपयोग की गई key को यह अतिरिक्त अनुमति देनी पड़ सकती है। Python के लिए requests या shell उदाहरण के लिए jq इंस्टॉल करें। दोनों उदाहरण एक संस्करण पिन करते हैं, फ़िल्टर अपरिवर्तित रखते हैं और redirect अस्वीकार करते हैं। वे त्रुटियों पर और 1,000 पेज के बाद रुक जाते हैं, ताकि अधूरे walk को पूर्ण के रूप में रिपोर्ट न किया जाए। Python का read timeout निष्क्रियता की अवधि को सीमित करता है, कुल कार्य-अवधि को नहीं; अपने इंटीग्रेशन में कार्य की समय-सीमा निर्धारित करें। तब तक पेज का अनुरोध करते रहें जब तक next_page_token का मान null न हो जाए। बल्क रीड के लिए limit=500 को प्राथमिकता दें, ताकि कम अनुरोधों में पूरा संग्रह कवर हो — देखें rate limits।

Keep filters stable while paginating

पेज टोकन अपारदर्शी, हस्ताक्षरित कर्सर होते हैं। प्रत्येक टोकन उस अनुरोध के संगठन, प्रमाणीकृत service account, contract संस्करण और सटीक फ़िल्टर समूह से बंधा होता है जिसने उसे उत्पन्न किया। walk के बीच में इनमें से किसी को भी बदलने पर — उदाहरण के लिए, दूसरे पेज पर type फ़िल्टर जोड़ने पर — page_token पैरामीटर पर कोड invalid_request के साथ 400 लौटता है:
400 Invalid request
फ़िल्टर बदलने के लिए, पहले पेज से नया walk शुरू करें।
page_token को अपारदर्शी स्ट्रिंग मानें: इसे ठीक उसी रूप में वापस पास करें जिस रूप में यह प्राप्त हुआ। टोकन को decode न करें, दीर्घकालिक रूप से संग्रहीत न करें और न ही स्वयं बनाएँ — उनका आंतरिक प्रारूप बिना सूचना के किसी भी समय बदल सकता है।
List endpoint उन query पैरामीटर को अस्वीकार करते हैं जिन्हें वे समर्थित नहीं करते, और उस पैरामीटर का नाम बताते हुए 400 invalid_request लौटाते हैं। समर्थित फ़िल्टर के लिए प्रत्येक endpoint का संदर्भ देखें।

Handle an interrupted or changing collection

ये उदाहरण त्रुटियों को स्वचालित रूप से पुनः प्रयास नहीं करते। 429 के लिए Retry-After का पालन करें और सीमित retry guidance का अनुसरण करें। रीड को पुनः प्रयास करते समय वही region, service account, संस्करण, फ़िल्टर और अंतिम सफलतापूर्वक संसाधित पेज टोकन रखें। credentials बदलने से एक्सेस नहीं मिल जाता: प्रत्येक अनुरोध में वर्तमान अनुमतियों की जाँच फिर भी होती है। बहु-पेज रीड संग्रह का स्नैपशॉट नहीं होता। आपके traverse करते समय पंक्तियाँ बदल सकती हैं। संसाधनों को उनके स्थिर id द्वारा संसाधित करें और डाउनस्ट्रीम राइट्स को idempotent बनाएँ; पुनः आरंभ करने पर कोई पंक्ति फिर से लौट सकती है। यदि कोई टोकन अस्वीकार किया जाता है, तो page_token त्रुटि की जाँच करें और पहले पेज से पुनः आरंभ करने से पहले अनुरोध को सुधारें। पहले संसाधित डेटा को चुपचाप न हटाएँ और न ही बाधित export को पूर्ण के रूप में चिह्नित करें। रिपोर्टिंग के सटीक कुल योग के लिए, लाइव सूची traversal को स्नैपशॉट मानने के बजाय उपयुक्त reporting resource का उपयोग करें।