API के साथ TRON एनर्जी किराये को कैसे ऑटोमेट करें

2026-05-13

एनर्जी किराये को ऑटोमेट क्यों करें

अगर आप हॉट वॉलेट, एक्सचेंज विदड्रॉल इंजन, या ऐसा कॉन्ट्रैक्ट चला रहे हैं जो उपयोगकर्ताओं की ओर से TRC-20 ट्रांसफर ट्रिगर करता है, तो आपको पहले से ही दिक्कत पता है: जिस सेकंड कोई ट्रांज़ैक्शन फायर होता है, उस सेकंड TRON एनर्जी तैयार होनी चाहिए। UI के माध्यम से हाथ से एनर्जी टॉप-अप करना दिन में कुछ ट्रांसफर से आगे स्केल नहीं करता। विंडो चूक गए और ट्रांज़ैक्शन भेजने वाले पते से TRX जला देगा, अक्सर पहले से किराये पर ली गई एनर्जी से कहीं ज़्यादा कीमत पर।

समाधान यह है कि जिस क्षण आपका बैकएंड कोई ट्रांज़ैक्शन ब्रॉडकास्ट करने वाला हो, उसी क्षण किराये का API कॉल करें, ताकि एनर्जी प्रोग्रामेटिक रूप से प्रोविज़न हो जाए और लूप में कोई मानव न हो। यह लेख ठीक से बताता है कि tronenergyrent.com के विरुद्ध यह कैसे करें: असली रिक्वेस्ट संरचना, असिंक्रोनस ऑर्डर लाइफसाइकल, समझदार अवधि के ट्रेडऑफ, और एक कार्यशील Python उदाहरण जिसे आप अपनी सर्विस में डाल सकते हैं।

API वास्तव में ऑन-चेन क्या करता है

कोड लिखने से पहले, ऑन-चेन मैकेनिक्स को समझना उपयोगी है ताकि आप अंधेरे में डिबग न कर रहे हों।

TRON का रिसोर्स मॉडल कंप्यूटेशन (एनर्जी) को ट्रांज़ैक्शन आकार (bandwidth) से अलग करता है। एक स्टैंडर्ड USDT TRC-20 ट्रांसफर लगभग 65,000 एनर्जी की खपत करता है जब प्राप्तकर्ता के पास पहले से USDT है, और लगभग 130,000 जब प्राप्तकर्ता का USDT बैलेंस शून्य है। पहला आने वाला ट्रांसफर बैलेंस एंट्री बनाने की स्टोरेज लागत चुकाता है, इसीलिए लागत पूरी तरह प्राप्तकर्ता पर निर्भर करती है, भेजने वाले पर नहीं। ट्रांसफर के लिए bandwidth का उपयोग लगभग 345 बाइट्स होता है, जो इतना छोटा है कि अधिकांश खाते इसे अपने दैनिक मुफ्त भत्ते से कवर कर लेते हैं।

जब आप किराये का API कॉल करते हैं, तो सर्विस अपना खुद का TRX स्टेक करती है और Stake 2.0 के DelegateResourceContract का उपयोग करके परिणामी एनर्जी को आपके निर्दिष्ट पते को डेलिगेट करती है। डेलिगेशन पता-विशिष्ट और समय-सीमित होता है। एक बार किराये की अवधि समाप्त होने पर, एनर्जी प्रोवाइडर द्वारा स्वचालित रूप से वापस ले ली जाती है।

एक महत्वपूर्ण विवरण: किराया असिंक्रोनस होता है। API कॉल तुरंत orderId और PAID_BY_USER स्थिति के साथ रिटर्न करता है, लेकिन ऑन-चेन डेलिगेशन ट्रांज़ैक्शन बैकग्राउंड में ब्रॉडकास्ट होता है और आम तौर पर कुछ सेकंड के भीतर पूरा हो जाता है। आपके इंटीग्रेशन को प्रारंभिक प्रतिक्रिया को ऑर्डर स्वीकृत और भुगतान की पुष्टि के रूप में मानना चाहिए, फिर ऑर्डर डिटेल्स एंडपॉइंट को तब तक पोल करें जब तक स्थिति ENERGY_DELEGATED तक नहीं पहुँच जाती।

सही किराये की अवधि चुनना

API period पैरामीटर स्वीकार करता है जिसके चार अनुमत मान हैं: 1h, 1d, 3d, 30d। कीमतें ऑन-चेन एनर्जी मार्केट के साथ बदलती रहती हैं और दिन भर में बदलती हैं, इसलिए लाइव संख्याएँ हमेशा प्राइसिंग पेज पर रहती हैं। सापेक्ष क्रम स्थिर है: 1h प्रति कॉल सबसे सस्ता है, 30d सबसे सस्ता है जब इसे एक ही पते से कई ट्रांसफर पर एमॉर्टाइज़ किया जाए।

एक इवेंट-ड्रिवन सिस्टम के लिए जहाँ आप प्रति आउटगोइंग ट्रांसफर एक किराया ट्रिगर करते हैं, 1h टियर लगभग हमेशा सही विकल्प है। आप सबसे कम पूर्ण लागत चुकाते हैं और एनर्जी डेलिगेट होने के सेकंडों के भीतर खपत हो जाती है। 1d और लंबे टियर तब समझ में आते हैं जब आप पूर्वानुमेय बैच वर्कलोड चला रहे हों, उदाहरण के लिए एक रात्रिकालीन पेआउट जॉब, और एक बड़ा एनर्जी ब्लॉक एक बार किराये पर लेना चाहते हों बजाय API को दर्जनों बार कॉल करने के।

अगर आपका सिस्टम लगातार एक ही पते से प्रति घंटा 20-30 से अधिक ट्रांसफर फायर करता है, तो आपके अपेक्षित वॉल्यूम को कवर करने के लिए आकार वाला 1d ब्लॉक किराये पर लेना प्रति-ट्रांसफर कॉल से अधिक साफ है। अग्रिम लागत बढ़ जाती है लेकिन API ओवरहेड और ऑन-चेन कन्फर्मेशन लेटेंसी हॉट पाथ से गायब हो जाती है।

प्रमाणीकरण और रिक्वेस्ट संरचना

किराये का एंडपॉइंट यहाँ रहता है:

GET https://api.tronenergyrent.com/place-energy-order

यह एक सादा GET रिक्वेस्ट है जिसमें क्वेरी पैरामीटर हैं। प्रमाणीकरण apiKey क्वेरी पैरामीटर है, जिसे आप पंजीकरण करने और अपने खाते में फंड डालने के बाद अपने डैशबोर्ड से जनरेट करते हैं। इस एंडपॉइंट के लिए हेडर-आधारित प्रमाणीकरण नहीं है और न ही JSON रिक्वेस्ट बॉडी है।

पैरामीटर ये हैं:

  • apiKey (अनिवार्य): डैशबोर्ड से आपकी API कुंजी।
  • period (अनिवार्य): किराये की अवधि, 1h, 1d, 3d, 30d में से एक।
  • energyAmount (अनिवार्य): कितनी एनर्जी डेलिगेट करनी है। न्यूनतम 15000 है। ऐसे प्राप्तकर्ता को एक स्टैंडर्ड USDT ट्रांसफर के लिए जिसके पास पहले से USDT है, 65000 सुरक्षित संख्या है; नए USDT धारक को पहले ट्रांसफर के लिए, 130000 का उपयोग करें।
  • destinationAddress (अनिवार्य): TRON पता (base58check, T से शुरू होता है) जो डेलिगेटेड एनर्जी प्राप्त करेगा।
  • preActivateDestinationAddress (वैकल्पिक, डिफ़ॉल्ट 0): 1 पर सेट करें यदि गंतव्य पते ने कभी कोई TRX प्राप्त नहीं किया है और इसलिए ऑन-चेन सक्रिय नहीं है। तब सर्विस एनर्जी डेलिगेट करने से पहले पते को सक्रिय करने के लिए आपके प्रीपेड बैलेंस से 1.5 TRX भेजती है। यदि पता पहले से सक्रिय है, तो अतिरिक्त लागत से बचने के लिए इसे 0 पर छोड़ दें।

प्रतिक्रिया हमेशा HTTP स्टेटस 200 के साथ लौटाई जाती है, इस बात पर ध्यान दिए बिना कि ऑर्डर सफल हुआ या विफल। HTTP स्टेटस के बजाय JSON बॉडी के status फ़ील्ड पर ब्रांच करें। एक सफलता बॉडी ऐसी दिखती है:

{
  "status": "SUCCESS",
  "errorCode": null,
  "errorDescription": null,
  "requestId": "2651eacd-2428",
  "payload": {
    "orderId": "128de799-501e-44b2-8d6f-1fa825c2deed",
    "totalPriceSun": 5662800,
    "totalPriceTrx": 5.6628,
    "state": "PAID_BY_USER"
  }
}

एक त्रुटि बॉडी में status: "ERROR", एक मशीन-पठनीय errorCode, और एक मानव-पठनीय errorDescription होता है:

{
  "status": "ERROR",
  "errorCode": "INVALID_ENERGY_AMOUNT",
  "errorDescription": "energyAmount is less than 15000",
  "requestId": "71431087-4",
  "payload": null
}

दोनों ब्रांच पर requestId हमेशा लॉग करें। अगर आपको कभी सपोर्ट से किसी विशिष्ट किराये को ट्रेस करने के लिए कहना पड़े, तो वे उसी ID पर खोज करते हैं।

ऑर्डर लाइफसाइकल

payload में state फ़ील्ड एक छोटे निश्चित अनुक्रम से होकर आगे बढ़ता है:

  • PAID_BY_USER: प्रारंभिक स्थिति, ऑर्डर आपके बैलेंस से भुगतान कर दिया गया है लेकिन अभी तक कोई ऑन-चेन क्रिया नहीं हुई है।
  • WAITING_DELEGATION: सर्विस ने ऑर्डर उठा लिया है और डेलिगेशन ट्रांज़ैक्शन तैयार कर रही है।
  • ENERGY_DELEGATED: डेलिगेशन ट्रांज़ैक्शन ऑन-चेन पूरा हो चुका है। गंतव्य पते के पास अब किराये पर ली गई एनर्जी है और वह अगले आउटबाउंड ट्रांज़ैक्शन पर इसे खर्च कर सकता है।
  • ERROR_DELEGATION: किसी कारण से डेलिगेशन विफल हो गया। दुर्लभ, लेकिन भारी नेटवर्क भीड़ के दौरान संभव।
  • CANCELLED: ऑर्डर रद्द कर दिया गया और फंड आपके बैलेंस में वापस कर दिए गए।

वर्तमान स्थिति जांचने के लिए, कॉल करें:

GET https://api.tronenergyrent.com/single-order-details?apiKey=YOUR_API_KEY&orderId=ORDER_ID

प्रतिक्रिया उसी status / errorCode / payload लिफाफे का उपयोग करती है, जिसके payload के अंदर वर्तमान state होती है। ऑर्डर देने के बाद इसे हर एक या दो सेकंड में पोल करें और ENERGY_DELEGATED देखने के बाद ही अपने TRC-20 ट्रांसफर के साथ आगे बढ़ें। व्यवहार में यह आमतौर पर एक या दो पोल होते हैं।

एक कार्यशील Python इंटीग्रेशन

यहाँ एक न्यूनतम लेकिन प्रोडक्शन-आकार का पैटर्न है। यह किराया देता है, डेलिगेशन ऑन-चेन होने तक पोल करता है, और अगर कुछ गलत होता है तो स्पष्ट त्रुटि सामने लाता है।

import logging
import time
import requests

API_BASE = "https://api.tronenergyrent.com"
API_KEY = "your_api_key_here"
ENERGY_FOR_TRANSFER = 65_000   # use 130_000 if recipient has zero USDT balance
HTTP_TIMEOUT_SECS = 10
POLL_INTERVAL_SECS = 1
POLL_TIMEOUT_SECS = 30


def place_order(destination_address: str, period: str = "1h",
                energy_amount: int = ENERGY_FOR_TRANSFER) -> dict:
    resp = requests.get(
        f"{API_BASE}/place-energy-order",
        params={
            "apiKey": API_KEY,
            "period": period,
            "energyAmount": energy_amount,
            "destinationAddress": destination_address,
            "preActivateDestinationAddress": 0,
        },
        timeout=HTTP_TIMEOUT_SECS,
    )
    resp.raise_for_status()
    body = resp.json()
    if body.get("status") != "SUCCESS":
        raise RuntimeError(
            f"place-energy-order failed: {body.get('errorCode')} "
            f"({body.get('errorDescription')}) requestId={body.get('requestId')}"
        )
    return body["payload"]


def wait_for_delegation(order_id: str) -> dict:
    deadline = time.monotonic() + POLL_TIMEOUT_SECS
    while time.monotonic() < deadline:
        resp = requests.get(
            f"{API_BASE}/single-order-details",
            params={"apiKey": API_KEY, "orderId": order_id},
            timeout=HTTP_TIMEOUT_SECS,
        )
        resp.raise_for_status()
        body = resp.json()
        if body.get("status") != "SUCCESS":
            raise RuntimeError(
                f"single-order-details failed: {body.get('errorCode')} "
                f"({body.get('errorDescription')})"
            )
        state = body["payload"]["state"]
        if state == "ENERGY_DELEGATED":
            return body["payload"]
        if state == "ERROR_DELEGATION":
            raise RuntimeError(f"Delegation failed for order {order_id}")
        if state == "CANCELLED":
            raise RuntimeError(f"Order {order_id} was cancelled")
        time.sleep(POLL_INTERVAL_SECS)
    raise TimeoutError(f"Order {order_id} did not reach ENERGY_DELEGATED in {POLL_TIMEOUT_SECS}s")


def rent_energy(destination_address: str) -> dict:
    placed = place_order(destination_address)
    logging.info(
        "Order placed: id=%s priceSun=%s priceTrx=%s",
        placed["orderId"], placed["totalPriceSun"], placed["totalPriceTrx"],
    )
    delegated = wait_for_delegation(placed["orderId"])
    logging.info("Order delegated: id=%s", delegated["orderId"])
    return delegated

कुछ बातें ध्यान देने योग्य हैं। स्पष्ट status == "SUCCESS" जाँच महत्वपूर्ण है क्योंकि HTTP स्टेटस हमेशा 200 होता है, इसलिए केवल resp.raise_for_status() आपको वास्तविक परिणाम के बारे में कुछ नहीं बताता। पोलिंग लूप में एक कठोर टाइमआउट है ताकि अटका हुआ ऑर्डर आपके ट्रांसफर पाइपलाइन को अनिश्चित काल तक ब्लॉक न कर सके। state पर ब्रांचिंग एक सामान्य "not success" पर निर्भर रहने के बजाय तीनों टर्मिनल परिणामों (ENERGY_DELEGATED, ERROR_DELEGATION, CANCELLED) को स्पष्ट रूप से संभालती है।

अपने ट्रांसफर वर्कफ़्लो में, पहले rent_energy() कॉल करें, फिर TRC-20 ट्रांसफर ब्रॉडकास्ट करें। ऑपरेशन का क्रम मायने रखता है: पहले ब्रॉडकास्ट करेंगे तो ट्रांज़ैक्शन भेजने वाले से TRX जला देगा क्योंकि डेलिगेशन अभी तक पूरा नहीं हुआ है।

अपने प्रीपेड बैलेंस का आकार तय करना

किराये की लागत आपके tronenergyrent.com खाते में आपके द्वारा बनाए गए प्रीपेड बैलेंस से काटी जाती है। एक थ्रेशोल्ड से नीचे बैलेंस गिरने पर अलर्ट या स्वचालित टॉप-अप सेट करें। एक उचित न्यूनतम वह है जो पीक वॉल्यूम के दो घंटे को कवर करे।

प्रोग्रामेटिक रूप से वर्तमान बैलेंस पढ़ने के लिए:

GET https://api.tronenergyrent.com/account-info?apiKey=YOUR_API_KEY

payload में आपका वर्तमान बैलेंस और खाते की स्थिति शामिल है। उसे अपने मॉनिटरिंग स्टैक में जोड़ें और आप कभी भी रात के 2 बजे खाली बैलेंस से चौंकेंगे नहीं। ध्यान दें कि tronenergyrent.com बैलेंस में न्यूनतम टॉप-अप 10 TRX है।

व्यवहार में त्रुटि हैंडलिंग

प्रोडक्शन में तीन फेलियर मोड सबसे अधिक सामने आते हैं। नीचे दिए गए त्रुटि कोड असली API से आते हैं और आप उन पर सुरक्षित रूप से ब्रांच कर सकते हैं।

  1. INSUFFICIENT_BALANCE: आपका प्रीपेड बैलेंस अनुरोधित किराये और किसी भी प्री-एक्टिवेशन को कवर करने के लिए बहुत कम है। पुनः प्रयास न करें, पुनः प्रयास करने से यह ठीक नहीं होगा। इसे विशेष रूप से पकड़ें और अलर्ट या टॉप-अप फ़्लो ट्रिगर करें। अपने अलर्ट payload में requestId जोड़ें।
  2. INVALID_ADDRESS: destinationAddress सर्वर पर base58check डिकोड में विफल हो गया। अगर आपका सिस्टम पते डायनेमिक रूप से बनाता है, उदाहरण के लिए उपयोगकर्ता-आपूर्ति इनपुट से, तो API को कॉल करने से पहले उन्हें स्थानीय रूप से सत्यापित करें। tronpy Python लाइब्रेरी में इसके लिए is_address() है; क्लाइंट-साइड पर खराब इनपुट को अस्वीकार करना राउंड ट्रिप की प्रतीक्षा करने से तेज़ है।
  3. INACTIVE_DESTINATION_ADDRESS_ERROR: गंतव्य पता कभी ऑन-चेन सक्रिय नहीं किया गया है और आपने सर्विस से इसे सक्रिय करने के लिए नहीं कहा। इसे ठीक करने के लिए या तो पते को कहीं और से थोड़ी मात्रा में TRX के साथ पहले से फंड करें, या अगली कॉल पर preActivateDestinationAddress=1 पास करें ताकि सर्विस इसे 1.5 TRX में सक्रिय कर दे।

एक सूक्ष्म मामला: ORDER_IS_ALREADY_IN_PROGRESS तब वापस आ सकता है जब आपके कई वर्कर एक ही समय में एक ही गंतव्य के लिए किराये दे रहे हों। समाधान प्रोसेस-साइड है, API-साइड नहीं। गंतव्य पते पर की गई एक डिस्ट्रीब्यूटेड लॉक (Redis ठीक काम करता है) लें और डेलिगेशन पूरा होने तक इसे रोक कर रखें।

ऑन-चेन सत्यापन

अधिकांश इंटीग्रेशन के लिए, /single-order-details को ENERGY_DELEGATED तक पोल करना पर्याप्त है। यदि आप दो-स्तरीय सत्यापन चाहते हैं, तो डेलिगेशन पूरा होने के बाद आप TRON फुल नोड को सीधे भी क्वेरी कर सकते हैं:

GET https://api.trongrid.io/v1/accounts/{destinationAddress}

प्रतिक्रिया में पते की वर्तमान रिसोर्स स्थिति शामिल होती है, जिसमें बाहरी पतों से इसे डेलिगेट की गई एनर्जी भी शामिल है। सटीक फ़ील्ड नाम वर्तमान Stake 2.0 दृश्य पर निर्भर करता है, इसलिए इसे जोड़ते समय लाइव TRON HTTP API डॉक्स से सलाह लें। ट्रांसफर को ब्लॉक करने के बजाय चेतावनी लॉग करने वाली एक नरम जाँच के रूप में, यह उन दुर्लभ मामलों के लिए उपयोगी कैनरी है जब स्वयं किराये के API के डाउनस्ट्रीम में कुछ गलत हो जाता है।

वह अतिरिक्त जाँच उस एक बार के लिए घंटों की डिबगिंग बचाएगी जब किराया API में सफल दिखता है लेकिन ऑन-चेन कुछ और गलत हो जाता है।

TRON ट्रांजैक्शन फीस बचाना चाहते हैं? अभी एनर्जी की कीमतें देखें। कीमत अनुमान
ब्लॉग पर वापस जाएं

TRON एनर्जी रेंट सपोर्ट से संपर्क करें

उपयोगी पृष्ठ