मुख्य सामग्री पर जाएं

​
एंडपॉइंट

एंडपॉइंट एक Node API कुंजी है। प्लान या ट्रायल मिलने के बाद आप एंडपॉइंट डैशबोर्ड → Node API में बनाते हैं। हर एंडपॉइंट के पास होता है:
  • अपनी कुंजी;
  • अपनी IP अनुमति सूची;
  • अपना उपयोग काउंटर — मौजूदा अवधि के WU और कॉल, जो डैशबोर्ड में दिखते हैं।
कोटा और प्रति सेकंड सीमाएँ आपके प्लान की होती हैं और उसके सभी एंडपॉइंट में साझा होती हैं: दूसरा एंडपॉइंट आपको अलग कुंजी और काउंटर देता है, ज़्यादा थ्रूपुट नहीं। आपके कितने एंडपॉइंट हो सकते हैं, यह प्लान पर निर्भर करता है — देखें प्लान और बिलिंग। कुंजी केवल एक बार दिखाई जाती है, एंडपॉइंट बनाते समय। अगर वह खो जाए, तो एंडपॉइंट हटाकर नया बनाएँ। डैशबोर्ड में आप एंडपॉइंट की IP अनुमति सूची संपादित भी कर सकते हैं, उसे बंद और चालू कर सकते हैं, और उसे हटा सकते हैं:
डैशबोर्ड में किए गए बदलाव — नया एंडपॉइंट, नई IP अनुमति सूची, बंद या हटाया गया एंडपॉइंट, भुगतान किया गया रिन्यूअल — लगभग 30 सेकंड में नोड गेटवे तक पहुँचते हैं। इस दौरान अभी-अभी बनाई गई कुंजी को 401 unknown_key मिल सकता है।

​
Node API कुंजियाँ और REST API कुंजियाँ

Node API कुंजियाँ एक अलग तरह की कुंजी हैं। एंडपॉइंट की कुंजी केवल node.tronrental.com पर काम करती है; TronRental REST API (api.tronrental.com) उसे 403 NODE_API_KEY_ONLY के साथ अस्वीकार करता है। उसी तरह, आपकी REST API कुंजियाँ नोड पर काम नहीं करतीं और वहाँ उन्हें 401 unknown_key मिलता है।

​
HTTP पर कुंजी भेजना

कुंजी इनमें से किसी एक जगह भेजें: हेडर के नाम केस-सेंसिटिव नहीं हैं। पाथ में दी गई कुंजी रिक्वेस्ट को नोड तक भेजने से पहले हटा दी जाती है, इसलिए नोड उसे कभी नहीं देखता।
एक रिक्वेस्ट में एक कुंजी होती है। वही कुंजी दो बार भेजना (उदाहरण के लिए, पाथ में और हेडर में) ठीक है; दो अलग-अलग कुंजियाँ 400 key_conflict के साथ अस्वीकार होती हैं, क्योंकि हम यह तय नहीं कर सकते कि भुगतान उनमें से किसे करना चाहिए।
पाथ में दी गई कुंजी URL का हिस्सा है, इसलिए वह हर उस जगह पहुँच जाती है जहाँ URL दर्ज होते हैं: प्रॉक्सी और एप्लिकेशन लॉग, मॉनिटरिंग, ब्राउज़र इतिहास। अगर आपका क्लाइंट हेडर सेट करने देता है, तो हेडर चुनें।

​
लाइब्रेरी

TronWeb वही हेडर भेजता है जो आप उसे देते हैं:
tronpy api_key= सिर्फ़ अपने डिफ़ॉल्ट होस्ट को भेजता है, इसलिए हमारे पते के साथ वह कोई कुंजी भेजेगा ही नहीं। प्रोवाइडर के सेशन पर हेडर खुद सेट करें — या कुंजी पाथ में रखें, आख़िर में स्लैश के साथ: उसके बिना tronpy पते का आख़िरी सेगमेंट छोड़ देता है, और उसके साथ कुंजी भी।

​
gRPC पर कुंजी भेजना

हर कॉल के tron-pro-api-key मेटाडेटा में कुंजी भेजें (x-api-key और authorization: Bearer <YOUR_KEY> भी काम करते हैं)। gRPC में कुंजी ले जाने के लिए कोई पाथ नहीं होता। देखें gRPC।

​
IP अनुमति सूची

हर एंडपॉइंट को IP पतों की सूची तक सीमित किया जा सकता है — IPv4 या IPv6, सटीक पते, रेंज नहीं। खाली सूची के साथ कुंजी किसी भी पते से काम करती है। सूची होने पर किसी अन्य पते से आई रिक्वेस्ट को 403 ip_not_allowed मिलता है। IPv6 रूप में लिखा गया IPv4 पता (::ffff:203.0.113.7) खुद उसी IPv4 पते के रूप में गिना जाता है।

​
ब्राउज़र ऐप (CORS)

Node API किसी भी origin से आई ब्राउज़र रिक्वेस्ट का जवाब देता है, इसलिए कोई dApp इसे सीधे कॉल कर सकता है:
ब्राउज़र कोड में रखी कुंजी आपका ऐप खोलने वाले हर व्यक्ति को दिखती है, और जो भी उसे कॉपी करता है, वह आपका कोटा खर्च करता है। IP अनुमति सूची यहाँ मदद नहीं करती — आपके उपयोगकर्ताओं के पते पहले से पता नहीं होते। ब्राउज़र को उसका अपना एंडपॉइंट दें, उसके काउंटर पर नज़र रखें, और दुरुपयोग होने पर उसे हटा दें: आपके सर्वर की कुंजियाँ काम करती रहेंगी।