वेबसाइट का छिपा हुआ JSON API: आंतरिक एंडपॉइंट्स को कैसे खोजें और पार्सर ट्रैफ़िक को कम करें

पार्सर 400 केबी HTML खींचता है आठ फ़ील्ड के लिए, जो साइट खुद को 8 केबी के JSON उत्तर में देती है। पचास गुना का अंतर "सुंदर कोड" के बारे में नहीं है, यह रेजिडेंट प्रॉक्सी के लिए बिल के बारे में है, जहाँ आप हर गीगाबाइट के लिए भुगतान करते हैं। हम समझते हैं कि साइट के आंतरिक API को कैसे ढूंढना है, 2026 में इसे दोहराने में क्या बाधा है, और कब इस विचार को छोड़ देना चाहिए।

अगर HTML पहले से ही पार्स किया जा रहा है, तो छिपे हुए API की तलाश क्यों करें

लगभग कोई भी आधुनिक इंटरफेस — React, Vue, Angular, Next.js — पहले पृष्ठ का ढांचा लोड करता है, और डेटा अपने अंत बिंदुओं के लिए अलग-अलग अनुरोधों के माध्यम से खींचता है। ये अंत बिंदु प्रलेखित नहीं हैं, लेकिन वे मौजूद हैं, शुद्ध JSON का उत्तर देते हैं और बिना हेडलेस ब्राउज़र के उपलब्ध हैं।

आपको क्या मिलता है, जब आप उन पर जाते हैं:

• ट्रैफ़िक एक क्रम में गिरता है। एक सामान्य उत्पाद सूची के विश्लेषण में, HTML पृष्ठ लगभग 400 केबी का होता है जिसमें मार्कअप, शैलियाँ और ट्रैकर्स शामिल होते हैं, जबकि संबंधित JSON अंत बिंदु लगभग 8 केबी का होता है, जिसमें फ़ील्ड अधिक होते हैं: आंतरिक ID, शेष, उत्पाद विकल्प।
• ब्राउज़र की आवश्यकता नहीं है। JavaScript का रेंडरिंग चला जाता है, और इसके साथ — मेमोरी, प्रोसेसर और फ़ॉन्ट्स और एनालिटिक्स के लिए दर्जनों अतिरिक्त अनुरोध।
• डेटा पहले से ही संरचित है। कोई चयनकर्ता नहीं, जो CSS क्लास के परिवर्तन से टूटता है।
• कम अनुरोध — बैन के लिए कम कारण। ब्राउज़र में एक कैटलॉग पृष्ठ को रेंडर करना साइट पर दर्जनों अनुरोध है; API के माध्यम से समान डेटा का एक अनुरोध है।

रिज़िडेंट प्रॉक्सी पर प्रोजेक्ट के लिए यह सीधा बचत है: टैरिफ गीगाबाइट्स के अनुसार होता है, और रेंडरिंग से JSON पर स्विच करना आमतौर पर बिल को अधिक संकुचित करता है, जितना कि चित्रों को ब्लॉक करने के किसी भी उपाय से। संबंधित विषय — अन्य तरीकों से पार्सर ट्रैफ़िक को 5 गुना कैसे कम करें।

चरण-दर-चरण: अंत बिंदु कैसे खोजें

1. पहले जांचें कि क्या कोई आधिकारिक API है। लक्षित साइट पर /developers, /api, /docs पर जाएँ। सार्वजनिक प्रलेखित API संस्करणित होता है और डिप्रेकेशन के बारे में चेतावनी देता है — निजी चुपचाप बदलता है।
2. DevTools खोलें (F12) और Network टैब पर जाएँ, सुनिश्चित करें कि रिकॉर्डिंग चालू है।
3. Fetch/XHR फ़िल्टर चालू करें। यह चित्रों, फ़ॉन्ट्स और एनालिटिक्स को काटता है, केवल डेटा के लिए अनुरोध छोड़ता है।
4. सूची को साफ करें, ताकि प्रारंभिक लोडिंग का शोर हट जाए।
5. ज़रूरी डेटा को उत्तेजित करें: परिणाम को स्क्रॉल करें, "अगला पृष्ठ" पर क्लिक करें, फ़िल्टर लागू करें, कार्ड खोलें। जिस अनुरोध में आपकी रुचि है वह क्रिया के क्षण में प्रकट होगा।
6. अपने डेटा के साथ उत्तर खोजें। सबसे तेज़ तरीका — Network पैनल पर Ctrl+F: उस अद्वितीय मान की खोज करें, जो आप स्क्रीन पर देखते हैं (आर्टिकल, सटीक मूल्य, नाम का एक टुकड़ा), और देखें कि कौन सा अनुरोध इसे उत्पन्न करता है।
7. पूरा अनुरोध कॉपी करें: पंक्ति पर राइट-क्लिक → कॉपी → Copy as cURL. फिर इसे curlconverter के माध्यम से कोड में परिवर्तित करें — इस तरह आप कोई भी हेडर नहीं खोएँगे।

विशिष्ट पथ, जिन पर पहले ध्यान देना चाहिए: /api/, /v1/, /v2/, /search, /products, /listings, /graphql.

विशेष मामला: Next.js पर साइटें

यहाँ डेटा अक्सर किसी अलग अनुरोध की आवश्यकता नहीं होती — वे सीधे HTML में होते हैं। पुराने Pages Router पर यह __NEXT_DATA__ ब्लॉक है। App Router (Next.js 13 और नए) पर, हाइड्रेशन के लिए डेटा कई script नोड्स में self.__next_f.push() द्वारा वितरित किया गया है — यह React Server Components का सीरियलाइज्ड पेलोड है। इसे हाथ से पार्स करना अप्रिय है: चंक्स एक-दूसरे को $ प्रीफिक्स के माध्यम से संदर्भित करते हैं और मध्य पंक्ति में काटे जा सकते हैं। Python के लिए एक पुस्तकालय nextflight है, जो HTML से Flight-payload और कच्चे RSC उत्तर (हेडर के साथ अनुरोध RSC: 1) को पार्स करता है, और इसमें नामों के अनुसार खोजने का सुझाव देता है, न कि सूची के अनुक्रमांक के अनुसार — इस तरह पार्सर साइट के पुन-तैनाती को सहन करता है।

पैरामीटर का रिवर्स: पेजिनेशन और फ़िल्टर

पाया गया अंत बिंदु लगभग हमेशा पैरामीटरयुक्त होता है। तीन योजनाएँ मिलती हैं:

• पृष्ठों के अनुसार: ?page=3&per_page=20
• ऑफसेट और सीमा: ?offset=40&limit=20
• कर्सर: ?after=<token>&limit=20 — अगली पृष्ठ का टोकन पिछले उत्तर के शरीर में आता है

तीन नियम, जो डिबगिंग के घंटों को बचाते हैं:

• खाली पैक पर रुकें, न कि पूर्व-गणना की गई पृष्ठ संख्या पर: total काउंटर निजी API में अक्सर झूठा होता है, जितना आप चाहेंगे।
• वास्तविक पैक का आकार जांचें। 100 का अनुरोध किया, 20 आया — इसका मतलब है कि अंत बिंदु की अपनी सीमा है, और आपके पृष्ठों की गणना पहले से ही गलत है।
• पृष्ठ 500 पर न जाएँ। गहरी पेजिनेशन लगभग हर जगह सर्वर द्वारा काटी जाती है; इसके बजाय फ़िल्टर द्वारा चयन को काटें — श्रेणी, मूल्य सीमा, तिथि के अनुसार।

क्यों cURL ब्राउज़र से काम करता है, जबकि आपका कोड नहीं

यह असफलता का सबसे सामान्य बिंदु है, और कारण लगभग हमेशा एक ही होता है: खोया हुआ हेडर. कॉपी किया गया cURL पूरे अनुरोध का संदर्भ ले जाता है, जबकि कस्टम क्लाइंट नहीं।

जो आमतौर पर अनिवार्य होता है:

• कस्टम हेडर X- प्रीफिक्स के साथ — X-CSRF-Token, X-Requested-With: XMLHttpRequest और विभिन्न X-*-Token, जो फ्रंटेंड स्वंय जोड़ता है। इनके बिना आप 400–500 के रेंज में उत्तर प्राप्त करेंगे।
• Referer — एक संदर्भित हेडर, जो उपयोगकर्ता की क्रिया द्वारा उत्पन्न होता है। कई अंत बिंदु यह जांचते हैं कि अनुरोध "अपनी पृष्ठ से आया है"।
• Authorization: Bearer <JWT> — अल्पकालिक टोकन, आमतौर पर 15–60 मिनट के लिए। इसे हार्डकोड करना बेकार है: ताजा प्राप्त करना सीखना आवश्यक है।
• सत्र कुकीज़ — उन्हें सत्र वस्तु में रखें, न कि हाथ से कॉपी करें।
• POST के लिए सही Content-Type — application/json और application/x-www-form-urlencoded शरीर को अलग-अलग तरीके से एन्कोड करते हैं, और घोषित प्रकार के साथ असंगति चुपचाप अनुरोध को तोड़ देती है।

अगर टोकन कुकी में नहीं हैं, तो उन्हें कहाँ खोजें: HTML स्रोत में <script> के अंदर (Ctrl+F के माध्यम से ज्ञात मान द्वारा खोजें), JavaScript बंडल में, localStorage या IndexedDB में — DevTools में Application टैब।

जल के नीचे की चट्टानें, जिनके बारे में बाद में पता चलता है

निजी API बिना चेतावनी के बदलता है। इसका कोई संस्करण नहीं है, संगतता और समर्थन का कोई वादा नहीं है: फ्रंटेंड टीम गुरुवार की रात को फ़ील्ड का नाम बदल देती है, और आपका पार्सर खालीता इकट्ठा करता है। सुरक्षा "विश्वसनीय चयनकर्ता" नहीं है, बल्कि संरचना की निगरानी है: सुनिश्चित करें कि आवश्यक फ़ील्ड सही प्रकार में हैं; खाली मानों के हिस्से और रन में रिकॉर्ड की संख्या पर नज़र रखें; टूटे हुए रिकॉर्ड को छोड़ दें, लेकिन यदि दोष 10% से अधिक हो जाए तो अलार्म उठाएँ; कच्चे उत्तरों को संग्रहीत करें ताकि बाद में तुलना की जा सके।

API कभी-कभी पृष्ठ की तुलना में अधिक कठोर होता है। यह नियमित रूप से होता है: HTML आसानी से दिया जाता है, जबकि /api/ पर एक एंटी-बॉट होता है, जो TLS फ़िंगरप्रिंट और हेडर के संयोजन की जांच करता है। तब ट्रैफ़िक की बचत असफल अनुरोधों के हिस्से में वृद्धि में बदल जाती है, और लाभ समाप्त हो जाता है।

हस्ताक्षरित अनुरोध। यदि पैरामीटर में कुछ ऐसा दिखाई देता है जैसे sign, hash या _s, फ्रंटेंड JavaScript में हस्ताक्षर की गणना करता है। इसे पुन: उत्पन्न करना एक अलग परियोजना है, और अक्सर HTML पर रहना सस्ता होता है।

फ्रीक्वेंसी पर सीमाएँ। निजी अंत बिंदु धाराओं के लिए डिज़ाइन नहीं किए गए हैं: 1–2 अनुरोध प्रति सेकंड रखें, कनेक्शन और पढ़ने के लिए अलग-अलग टाइमआउट सेट करें (उदाहरण के लिए, 5 और 30 सेकंड), केवल अस्थायी त्रुटियों को दोहराएँ — 429, 500, 502, 503, 504 — और 401 और 404 को न छुएँ। एक्सपोनेंशियल डिले विथ जिटर अनिवार्य है, अन्यथा सभी वर्कर्स एक साथ दूसरे चक्र में चले जाएंगे। अधिक जानकारी के लिए — प्रॉक्सी के लिए टाइमआउट और रीट्राई लॉजिक पर।

कानूनी ढांचा। सार्वजनिक अनधिकृत अंत बिंदु एक स्थिति है, खाता में प्रवेश करना — मौलिक रूप से दूसरी: पंजीकरण का अर्थ है उपयोगकर्ता समझौते को स्वीकार करना। व्यक्तिगत डेटा GDPR के तहत आते हैं चाहे वे कितने भी आसानी से प्राप्त हों। तथ्य — मूल्य, विशेषताएँ, उपलब्धता — कॉपीराइट द्वारा संरक्षित नहीं हैं, जबकि पाठ और चित्र संरक्षित हैं।

HTML पर कब रहना है

छिपा हुआ API हमेशा लाभकारी नहीं होता। यदि आप पृष्ठों के विश्लेषण पर बने रहें, तो:

• साइट सर्वर-साइड है और कोई आंतरिक API नहीं है;
• अंत बिंदु को हस्ताक्षर या टोकन के रोटेशन की आवश्यकता है — इसे बनाए रखना पृष्ठ की तुलना में महंगा है;
• API पर सार्वजनिक पृष्ठों की तुलना में अधिक कठोर सुरक्षा है;
• आपको विशेष रूप से अंतिम परिणाम की आवश्यकता है, जिसे फ्रंटेंड कई स्रोतों से इकट्ठा करता है;
• आप दर्जनों साइटों का प्रबंधन कर रहे हैं: एकल HTML कन्वेयर निजी API के एक चिड़ियाघर की तुलना में बेहतर स्केल करता है।

API-पार्सिंग के लिए किस प्रकार की प्रॉक्सी लेनी चाहिए

JSON पर स्विच करना गणना को बदलता है, क्योंकि संकीर्ण स्थान स्थानांतरित होता है: ट्रैफ़िक कम हो जाता है, जबकि IP की गुणवत्ता और सत्र की स्थिरता की आवश्यकताएँ बढ़ जाती हैं।

• प्राधिकरण और एंटी-बॉट के बिना खुला अंत बिंदु। यहाँ डेटा सेंटर प्रॉक्सी पर्याप्त हैं: डेटा की मात्रा छोटी है, रेजिडेंट के लिए भुगतान करने की आवश्यकता नहीं है।
• एंटी-बॉट के पीछे या सत्र से बंधा अंत बिंदु। रेजिडेंट प्रॉक्सी की आवश्यकता है जिसमें चिपचिपा सत्र हो: टोकन, कुकी और IP को पूरी श्रृंखला में मेल खाना चाहिए, अन्यथा सर्वर दूसरे अनुरोध पर सत्र को रीसेट कर देगा। इस स्थिति में बिल भी मामूली रहेगा — JSON मोड में गीगाबाइट्स धीरे-धीरे खर्च होते हैं।
• मोबाइल एप्लिकेशन से डेटा। यदि वेब संस्करण बंद है, और एप्लिकेशन वही सरलता से देता है, तो अंत बिंदुओं को ट्रैफ़िक को इंटरसेप्ट करके खोजा जाता है — यह एक अलग प्रक्रिया है, जो mitmproxy के माध्यम से मोबाइल एप्लिकेशन का छिपा हुआ API खोजने के लेख में समझाया गया है।

संक्षेप में

DevTools में बीस मिनट अक्सर हेडलेस ब्राउज़र के साथ दिनों की लड़ाई को बदल देते हैं: Fetch/XHR फ़िल्टर, दृश्य मान द्वारा खोज, Copy as cURL — और आपके हाथ में एक कार्यशील अनुरोध है। फिर विवरण तय करते हैं: सभी हेडर को स्थानांतरित करना, पेजिनेशन योजना को पार्स करना, उत्तर की वैधता स्थापित करना और यह तर्कसंगत रूप से आकलन करना कि क्या अंत बिंदु स्वयं पृष्ठ की तुलना में अधिक सुरक्षित है। जहाँ निजी API काम करता है, वह ट्रैफ़िक की मात्रा और अनुरोधों की संख्या दोनों को कम करता है — यानी तुरंत प्रॉक्सी की लागत और बैन की संभावना।