POST /apiv2/usdt/analyze
TRON USDT ट्रांसफर लागत की गणना करें (प्राइवेट एंडपॉइंट — प्रमाणित)।
सार्वजनिक GET वैरिएंट के समान ही बिल्कुल वही TransferAnalysis पेलोड लौटाता है, लेकिन काफी उच्च दर सीमा (1/सेकंड के बजाय प्रति Kong नोड 50 अनुरोध/सेकंड) के साथ और URL के बजाय एक JSON बॉडी में पास किए गए अनुरोध डेटा के साथ। किसी भी प्रोडक्शन एकीकरण के लिए इस एंडपॉइंट का उपयोग करें।
एंडपॉइंट URL
POST https://netts.io/apiv2/usdt/analyzeप्रमाणीकरण
निम्नलिखित दो हेडर में से कोई भी स्वीकार किया जाता है (दोनों एक साथ समर्थित हैं; X-API-KEY को प्राथमिकता दी जाती है क्योंकि यह Netts के बाकी /apiv2/* API परिवेश से मेल खाता है):
| हेडर | आवश्यक | विवरण |
|---|---|---|
Content-Type | हाँ | application/json होना चाहिए। |
X-API-KEY | प्राथमिकता प्राप्त | आपकी Netts API कुंजी — बिल्कुल उसी प्रारूप में जो /apiv2/order1h और अन्य प्रमाणित Netts एंडपॉइंट्स के लिए उपयोग की जाती है। |
Authorization | एक विकल्प के रूप में स्वीकृत | Bearer {key} या केवल {key} (बिना किसी प्रीफिक्स के)। इसका उपयोग तब करें यदि आपके HTTP क्लाइंट में इन-बिल्ट बियरर/प्रमाणीकरण फ़्लो है। |
यदि दोनों हेडर भेजे जाते हैं, तो X-API-KEY को प्राथमिकता दी जाती है।
IP व्हाइटलिस्ट: जिस IP से अनुरोध हमारे एज तक पहुँचता है, उसे आपकी API कुंजी के लिए कॉन्फ़िगर की गई व्हाइटलिस्ट में होना चाहिए (अन्य /apiv2/* एंडपॉइंट्स के समान तंत्र)। गैर-व्हाइटलिस्टेड IP से आने वाले अनुरोध "Invalid API key or IP not in whitelist" के साथ 401 Unauthorized लौटाते हैं।
अपने order1h हेडर का पुन: उपयोग करना
यदि आप पहले से ही X-API-KEY: {key} के साथ /apiv2/order1h को कॉल करते हैं, तो आप बिल्कुल वही X-API-KEY हेडर /apiv2/usdt/analyze पर भेज सकते हैं — कैलकुलेटर अब इसे प्राथमिक प्रमाणीकरण हेडर के रूप में पहचानता है।
अनुरोध बॉडी
{
"sender_address": "TFLit1TFohBtT2f8UVCLFVPmZxawxqByYe",
"receiver_address": "TTKR9aQdJWTgXLK9cmzaDitT5VXE497thL"
}फ़ील्ड्स
| फ़ील्ड | प्रकार | आवश्यक | प्रतिबंध |
|---|---|---|---|
sender_address | string | हाँ | मान्य TRON पता — 34 वर्ण, T से शुरू होता है, मान्य base58 चेकसम। |
receiver_address | string | हाँ | मान्य TRON पता; sender_address से अलग होना चाहिए। |
TIP
कोई amount फ़ील्ड नहीं है। कैलकुलेटर दोनों पतों के बीच एकल USDT ट्रांसफर के लिए लागत और संसाधन आवश्यकताओं को लौटाता है; यदि आपको किसी विशिष्ट USDT राशि के लिए विवरण की आवश्यकता है, तो अनुशंसित energy को अपनी तरफ ट्रांसफर की संख्या से गुणा करें — एक एकल TRC-20 USDT ट्रांसफर राशि की परवाह किए बिना समान ~130 k energy की खपत करता है।
अनुरोध के उदाहरण
cURL (प्राथमिकता प्राप्त — X-API-KEY)
curl -X POST "https://netts.io/apiv2/usdt/analyze" \
-H "Content-Type: application/json" \
-H "X-API-KEY: YOUR_API_KEY" \
-d '{
"sender_address": "TFLit1TFohBtT2f8UVCLFVPmZxawxqByYe",
"receiver_address": "TTKR9aQdJWTgXLK9cmzaDitT5VXE497thL"
}'cURL (वैकल्पिक — Authorization)
curl -X POST "https://netts.io/apiv2/usdt/analyze" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{
"sender_address": "TFLit1TFohBtT2f8UVCLFVPmZxawxqByYe",
"receiver_address": "TTKR9aQdJWTgXLK9cmzaDitT5VXE497thL"
}'Python
import requests
API_KEY = "YOUR_API_KEY"
payload = {
"sender_address": "TFLit1TFohBtT2f8UVCLFVPmZxawxqByYe",
"receiver_address": "TTKR9aQdJWTgXLK9cmzaDitT5VXE497thL",
}
r = requests.post(
"https://netts.io/apiv2/usdt/analyze",
headers={
"Content-Type": "application/json",
"X-API-KEY": API_KEY, # preferred; same header as /apiv2/order1h
# or, equivalently:
# "Authorization": f"Bearer {API_KEY}",
},
json=payload,
timeout=15,
)
if r.status_code == 200:
data = r.json()["data"]
print("Energy needed:", data["requirements"]["energy_with_buffer"])
print("Total cost: ", data["costs"]["total_cost_trx"], "TRX")
print("Method: ", data["costs"]["recommended_method"])
elif r.status_code == 401:
print("Auth failed:", r.json())
elif r.status_code == 429:
print("Rate-limited — Retry-After:", r.headers.get("Retry-After"))
else:
print("Error:", r.status_code, r.json())प्रतिक्रिया
सफलता (200 OK)
सार्वजनिक एंडपॉइंट के समान ही एनवेलप:
{
"status": "success",
"data": { /* TransferAnalysis — see the public-endpoint page */ },
"current_utc_time": "2026-04-23 11:54:13",
"processing_time_ms": 20.14
}data का पूरा फ़ील्ड-दर-फ़ील्ड विवरण सार्वजनिक-एंडपॉइंट पृष्ठ पर है — देखें TransferAnalysis, AddressInfo, Requirements और Costs।
त्रुटियाँ
जाँच का क्रम
प्रमाणीकरण को बॉडी सत्यापन से पहले सत्यापित किया जाता है। यदि Authorization हेडर अनुपलब्ध/अमान्य है या आपका IP व्हाइटलिस्टेड नहीं है, तो आप हमेशा401 देखेंगे — भले ही JSON बॉडी भी विकृत (malformed) हो। पहले प्रमाणीकरण ठीक करें, फिर एक मान्य कुंजी के साथ पुन: परीक्षण करें; केवल तभी Pydantic बॉडी-सत्यापन त्रुटियाँ (422) सामने आएँगी।
| HTTP | बॉडी | कब |
|---|---|---|
| 401 | {"code": -1, "msg": "API key not provided (expected X-API-KEY or Authorization header)"} | न तो X-API-KEY और न ही Authorization हेडर मौजूद है। |
| 401 | {"code": -1, "msg": "Invalid API key or IP not in whitelist"} | अज्ञात कुंजी, या अनुरोध IP आपकी व्हाइटलिस्ट में नहीं है। |
| 404 | {"code": -1, "msg": "User not found"} | कुंजी मान्य है लेकिन उपयोगकर्ता रिकॉर्ड नहीं मिला (दुर्लभ)। |
| 422 | {"detail": [{"loc": ["body","sender_address"], "msg": "Invalid TRON address length", "type": "value_error"}]} | FastAPI/Pydantic बॉडी सत्यापन विफल रहा। स्थिति 422 Unprocessable Entity है, 400 नहीं। |
| 422 | {"detail": [{..., "msg": "Sender and receiver cannot be the same address", "type": "value_error"}]} | sender_address == receiver_address. |
| 429 | {"message": "API rate limit exceeded"} | एक Kong नोड पर 50 req/sec से अधिक निरंतर ट्रैफ़िक। |
| 500 | {"code": -1, "msg": "Internal server error"} | अप्रत्याशित सर्वर-साइड विफलता। |
दर सीमा
- 50 अनुरोध / सेकंड प्रति Kong नोड (
limit_by = ip, नीतिlocal)। minute/hourसीमाएँ निर्धारित नहीं हैं — केवल प्रति-सेकंड सीमा लागू होती है।- प्रत्येक प्रतिक्रिया मानक Kong हेडर ले जाती है:
RateLimit-Limit,RateLimit-Remaining,RateLimit-Reset,X-RateLimit-Limit-Second,X-RateLimit-Remaining-Second, और429परRetry-After।
429 प्रतिक्रिया का उदाहरण
HTTP/1.1 429 Too Many Requests
Content-Type: application/json; charset=utf-8
RateLimit-Limit: 50
RateLimit-Remaining: 0
RateLimit-Reset: 1
Retry-After: 1
X-RateLimit-Limit-Second: 50
X-RateLimit-Remaining-Second: 0
{"message":"API rate limit exceeded"}TIP
यदि आप एकल API कुंजी के साथ 50 req/sec तक पहुँच रहे हैं और अधिक की आवश्यकता है, तो सहायता से संपर्क करें — सीमा को प्रति कुंजी बढ़ाया जा सकता है, या आपके उपभोक्ता से एक समर्पित दर-सीमा प्लगइन जोड़ा जा सकता है।
डिबग हेडर
प्रत्येक प्रतिक्रिया में सहायता टिकट खोलते समय उपयोगी पहचानकर्ता भी शामिल होते हैं — कृपया उन्हें हूबहू शामिल करें ताकि हम कुछ ही सेकंड में अपने लॉग में अनुरोध ढूँढ सकें:
| हेडर | अर्थ |
|---|---|
X-Request-ID | एप्लिकेशन-साइड अनुरोध ID (कैलकुलेटर द्वारा जनरेट की गई)। |
X-Process-Time | मिलीसेकंड में एप्लिकेशन प्रोसेसिंग समय (अपस्ट्रीम, Kong को छोड़कर)। |
X-Kong-Request-Id | Kong-साइड अनुरोध ID (Kong एक्सेस लॉग में मौजूद)। |
क्लाइंट-साइड टाइमआउट और पुन: प्रयास
कैलकुलेटर प्रत्येक अनुरोध के लिए TRON नोड्स पर लाइव ऑन-चेन क्वेरी करता है, इसलिए लोड या धीमे अपस्ट्रीम नोड्स के तहत एक एकल कॉल में कई सेकंड लग सकते हैं। कम क्लाइंट टाइमआउट स्वस्थ प्रतिक्रियाओं पर भी विफल हो जाएंगे — यह इंटीग्रेटर्स की अधिकांश cURL error 28 (Connection timed out) रिपोर्टों का मूल कारण है।
अनुशंसित सेटिंग्स:
- टाइमआउट ≥ 15 सेकंड (30 s अधिक सुरक्षित है)। कई HTTP क्लाइंट द्वारा उपयोग किया जाने वाला डिफ़ॉल्ट 10 s बहुत कम है।
- HTTP 429 पर,
Retry-Afterहेडर (सेकंड) का सम्मान करें। पुन: प्रयास करने से पहले थोड़ा जिटर (जैसे 0–200 ms) जोड़ें, फिर यदि आप अभी भी 50 req/sec की सीमा पर पहुँचते हैं तो एक्सपोनेंशियल बैकऑफ़ का उपयोग करें। - HTTP 5xx या नेटवर्क त्रुटियों पर, एक्सपोनेंशियल बैकऑफ़ के साथ अधिकतम 2–3 बार पुन: प्रयास करें; एंडपॉइंट पर बार-बार अत्यधिक अनुरोध न भेजें।
- प्रति
(sender_address, receiver_address)युग्म के परिणाम को क्लाइंट-साइड पर 30–60 सेकंड के लिए कैश करें — अंतर्निहित संसाधन मूल्य और ऑन-चेन स्थिति शायद ही कभी इतनी तेज़ी से बदलते हैं कि अधिक बार पुनर्गणना की आवश्यकता हो।
ब्राउज़र / CORS समर्थन
यह एंडपॉइंट सर्वर-टू-सर्वर एकीकरण के लिए डिज़ाइन किया गया है और वर्तमान में ब्राउज़र से सीधे कॉल का समर्थन नहीं करता है: अपस्ट्रीम FastAPI ऐप केवल Access-Control-Allow-Methods: GET का विज्ञापन करता है, इसलिए क्रॉस-ओरिजिन POST के लिए प्रीफ़्लाइट OPTIONS ब्राउज़र में विफल हो जाएगा।
यदि आपको ब्राउज़र फ्रंट-एंड से कैलकुलेटर को कॉल करने की आवश्यकता है, तो कुंजी को क्लाइंट के सामने उजागर करने के बजाय अपने स्वयं के बैक-एंड (जिसमें API कुंजी होती है) के माध्यम से अनुरोध को प्रॉक्सी करें।
TIP
यदि आपके उपयोग के मामले में वैध रूप से API कुंजी के साथ ब्राउज़र-साइड POST की आवश्यकता है (जैसे किसी ज्ञात ऑरिजिन पर एक विश्वसनीय आंतरिक डैशबोर्ड), तो सहायता से संपर्क करें — आपके रूट के लिए Kong स्तर पर एक CORS प्लगइन जोड़ा जा सकता है।
नोट्स
- प्रतिक्रिया प्रारूप जानबूझकर सार्वजनिक एंडपॉइंट के समान रखा गया है, ताकि सार्वजनिक प्रतिक्रिया को पार्स करने वाला क्लाइंट कोड आपके प्रमाणित वैरिएंट में माइग्रेट करने के बाद भी काम करता रहे — केवल कॉल ही बदलती है।
- दोनों
X-API-KEY: {key}(प्राथमिकता प्राप्त,/apiv2/order1hके अनुरूप) औरAuthorization: Bearer {key}/Authorization: {key}स्वीकार किए जाते हैं; यदि दोनों भेजे जाते हैं, तोX-API-KEYको प्राथमिकता दी जाती है। - Cloudflare / रिवर्स-प्रॉक्सी मध्यस्थता इस एंडपॉइंट को उसी तरह प्रभावित नहीं करती है जैसे यह सार्वजनिक एंडपॉइंट को प्रभावित करती है, क्योंकि प्रमाणित ट्रैफ़िक प्रति-Kong-नोड दर-सीमित होता है और अनुरोध पर प्रति-उपभोक्ता सिमेंटिक्स सक्षम किए जा सकते हैं।