POST /apiv2/usdt/analyze

คำนวณต้นทุนการโอน TRON USDT (endpoint แบบส่วนตัว — ต้องมีการยืนยันตัวตน)

ส่งคืนเพย์โหลด TransferAnalysis เหมือนกับตัวแปร GET แบบสาธารณะทุกประการ แต่มีขีดจำกัดอัตราการเรียกใช้งาน (rate limit) ที่สูงกว่ามาก (50 req/sec ต่อโหนด Kong แทนที่จะเป็น 1/sec) และส่งข้อมูลคำขอในรูปแบบ JSON body แทนที่จะส่งผ่าน URL โปรดใช้ endpoint นี้สำหรับการผสานการทำงานบนระบบ Production ทั้งหมด

URL ของ Endpoint

POST https://netts.io/apiv2/usdt/analyze

การยืนยันตัวตน

รองรับส่วนหัว (header) ข้อใดข้อหนึ่งต่อไปนี้จากสองข้อนี้ (สามารถใช้ได้ทั้งสองแบบพร้อมกัน; แนะนำให้ใช้ X-API-KEY เนื่องจากสอดคล้องกับอินเทอร์เฟซ API /apiv2/* อื่นๆ ของ Netts):

ส่วนหัว	จำเป็น	คำอธิบาย
Content-Type	ใช่	ต้องเป็น application/json
X-API-KEY	แนะนำ	คีย์ API ของ Netts ของคุณ — รูปแบบเดียวกับที่ใช้สำหรับ /apiv2/order1h และ endpoint อื่นๆ ของ Netts ที่ต้องยืนยันตัวตนทุกประการ
Authorization	ยอมรับเป็นอีกหนึ่งทางเลือก	Bearer {key} หรือเพียงแค่ {key} (ไม่มีคำนำหน้า) ใช้ส่วนหัวนี้หากไคลเอนต์ HTTP ของคุณมีโฟลว์ bearer/auth ในตัว

หากส่งทั้งสองส่วนหัว ระบบจะใช้ X-API-KEY เป็นหลัก

IP whitelist: IP ที่ส่งคำขอมาถึงขอบระบบ (edge) ของเราจะต้องอยู่ในรายการที่อนุญาต (whitelist) ซึ่งกำหนดค่าไว้สำหรับคีย์ API ของคุณ (กลไกเดียวกับ endpoint /apiv2/* อื่นๆ) คำขอจาก IP ที่ไม่อยู่ใน whitelist จะส่งคืน 401 Unauthorized พร้อมข้อความ "Invalid API key or IP not in whitelist"

การนำส่วนหัว order1h ของคุณกลับมาใช้ใหม่

หากคุณเรียกใช้งาน /apiv2/order1h ด้วย X-API-KEY: {key} อยู่แล้ว คุณสามารถส่งส่วนหัว X-API-KEY เดิมไปยัง /apiv2/usdt/analyze ได้ทันที — ปัจจุบันเครื่องคำนวณรับรู้ว่าเป็นส่วนหัวการยืนยันตัวตนหลักแล้ว

เนื้อหาคำขอ (Request body)

{
    "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 หนึ่งรายการจะใช้ Energy เท่ากันที่ประมาณ ~130 k เสมอ ไม่ว่าจะโอนด้วยจำนวนเงินเท่าใดก็ตาม

ตัวอย่างคำขอ

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)

โครงสร้างเหมือนกับ endpoint สาธารณะทุกประการ:

{
    "status": "success",
    "data": { /* TransferAnalysis — see the public-endpoint page */ },
    "current_utc_time": "2026-04-23 11:54:13",
    "processing_time_ms": 20.14
}

คำอธิบายแบบละเอียดทีละฟิลด์ของ data จะอยู่ในหน้าของ endpoint สาธารณะ — โปรดดูที่ TransferAnalysis, AddressInfo, Requirements และ Costs

ข้อผิดพลาด

ลำดับการตรวจสอบ

การยืนยันตัวตนจะได้รับการตรวจสอบก่อนการตรวจสอบความถูกต้องของเนื้อหา (body) หากส่วนหัว Authorization หายไป/ไม่ถูกต้อง หรือ IP ของคุณไม่อยู่ใน whitelist คุณจะเห็นข้อผิดพลาด 401 เสมอ — แม้ว่า JSON body จะผิดรูปแบบก็ตาม ให้แก้ไขปัญหาการยืนยันตัวตนก่อน แล้วทดสอบใหม่ด้วยคีย์ที่ถูกต้อง หลังจากนั้นข้อผิดพลาดจากการตรวจสอบเนื้อหาโดย 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 ของคำขอไม่อยู่ใน whitelist ของคุณ
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"}	ปริมาณการใช้งานต่อเนื่องเกินกว่า 50 req/sec บนโหนด Kong
500	{"code": -1, "msg": "Internal server error"}	เกิดข้อผิดพลาดที่ไม่คาดคิดจากฝั่งเซิร์ฟเวอร์

ขีดจำกัดอัตราการเรียกใช้งาน (Rate limit)

• 50 คำขอ / วินาที ต่อโหนด Kong (limit_by = ip, นโยบาย local)
• ไม่มีการตั้งค่าขีดจำกัดแบบ minute / hour — บังคับใช้เฉพาะขีดจำกัดต่อวินาทีเท่านั้น
• ทุกการตอบกลับจะมีส่วนหัวมาตรฐานของ Kong แนบมาด้วย: RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, X-RateLimit-Limit-Second, X-RateLimit-Remaining-Second, และ Retry-After เมื่อเกิดรหัส 429

ตัวอย่างการตอบกลับเมื่อติดรหัส 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

หากคุณใช้งานถึงขีดจำกัด 50 req/sec ด้วยคีย์ API เดียวและต้องการเพิ่มขีดจำกัด โปรดติดต่อฝ่ายสนับสนุน — เราสามารถเพิ่มขีดจำกัดเป็นรายคีย์ได้ หรือสามารถติดตั้งปลั๊กอิน rate-limit เฉพาะสำหรับผู้ใช้งานของคุณได้

ส่วนหัวสำหรับการดีบัก (Debug headers)

ทุกการตอบกลับจะส่งตัวระบุข้อมูลที่เป็นประโยชน์เมื่อเปิดคำขอแจ้งปัญหาไปยังฝ่ายสนับสนุน — โปรดแนบข้อมูลเหล่านี้ตามจริงโดยไม่ดัดแปลง เพื่อให้เราสามารถค้นหาคำขอดังกล่าวในบันทึก (logs) ของเราได้ภายในไม่กี่วินาที:

ส่วนหัว	ความหมาย
X-Request-ID	รหัสคำขอฝั่งแอปพลิเคชัน (สร้างโดยเครื่องคำนวณ)
X-Process-Time	เวลาประมวลผลของแอปพลิเคชันในหน่วยมิลลิวินาที (ฝั่งต้นน้ำ ไม่รวม Kong)
X-Kong-Request-Id	รหัสคำขอฝั่ง Kong (มีอยู่ในบันทึกการเข้าถึงของ Kong)

การหมดเวลาและการลองใหม่ฝั่งไคลเอนต์ (Timeout and retry)

เครื่องคำนวณจะทำการสืบค้นข้อมูลบนเชนแบบสดไปยังโหนด TRON สำหรับแต่ละคำขอ ดังนั้นภายใต้สภาวะโหลดสูงหรือโหนดต้นน้ำตอบสนองช้า การเรียกใช้งานครั้งเดียวอาจใช้เวลาหลายวินาที การตั้งเวลาหมดเวลาของไคลเอนต์ที่สั้นเกินไปจะทำให้ล้มเหลวแม้ว่าคำตอบกลับจะสมบูรณ์ดีก็ตาม — นี่คือสาเหตุหลักของรายงานส่วนใหญ่เกี่ยวกับ cURL error 28 (Connection timed out) จากผู้ผสานระบบ

การตั้งค่าที่แนะนำ:

• ตั้งเวลาหมดเวลา (Timeout) ≥ 15 วินาที (30 วินาทีจะปลอดภัยยิ่งขึ้น) ค่าเริ่มต้น 10 วินาทีที่ไคลเอนต์ HTTP หลายตัวใช้กันนั้นสั้นเกินไป
• เมื่อพบ HTTP 429 ให้ปฏิบัติตามค่าในส่วนหัว Retry-After (วินาที) เพิ่มการหน่วงเวลาแบบสุ่มเล็กน้อย (เช่น 0–200 ms) ก่อนลองใหม่ จากนั้นใช้วิธี exponential backoff หากคุณยังคงชนขีดจำกัด 50 req/sec
• เมื่อพบ HTTP 5xx หรือข้อผิดพลาดของเครือข่าย ให้ลองใหม่ไม่เกิน 2–3 ครั้งด้วยวิธี exponential backoff และห้ามยิงคำขอซ้ำอย่างหนักหน่วงไปยัง endpoint
• แคชผลลัพธ์ไว้ที่ฝั่งไคลเอนต์เป็นเวลา 30–60 วินาที ต่อคู่ (sender_address, receiver_address) — ราคาของทรัพยากรและสถานะบนเชนเบื้องหลังแทบจะไม่มีการเปลี่ยนแปลงเร็วพอจนต้องคำนวณใหม่บ่อยกว่านี้

การรองรับเบราว์เซอร์ / CORS

Endpoint นี้ได้รับการออกแบบมาสำหรับการผสานการทำงานแบบ server-to-server และในปัจจุบันยังไม่รองรับการเรียกใช้โดยตรงจากเบราว์เซอร์: แอปพลิเคชัน FastAPI ต้นน้ำประกาศเฉพาะ Access-Control-Allow-Methods: GET เท่านั้น ดังนั้นคำขอ preflight OPTIONS สำหรับ POST ข้ามต้นทาง (cross-origin) จะล้มเหลวในเบราว์เซอร์

หากคุณต้องการเรียกใช้เครื่องคำนวณจากส่วนหน้าของเบราว์เซอร์ ให้ส่งคำขอผ่านพร็อกซีแบ็กเอนด์ของคุณเอง (ซึ่งเป็นส่วนที่ถือคีย์ API) แทนที่จะเปิดเผยคีย์ดังกล่าวไปยังไคลเอนต์

TIP

หากกรณีการใช้งานของคุณจำเป็นต้องทำ POST จากฝั่งเบราว์เซอร์พร้อมคีย์ API จริงๆ (เช่น แดชบอร์ดภายในที่เชื่อถือได้บนต้นทางที่ทราบแน่ชัด) โปรดติดต่อฝ่ายสนับสนุน — เราสามารถติดตั้งปลั๊กอิน CORS ที่ระดับ Kong สำหรับเส้นทางของคุณได้

หมายเหตุ

• รูปแบบการตอบกลับได้รับการออกแบบให้เหมือนกับ endpoint สาธารณะโดยเจตนา ดังนั้นโค้ดของไคลเอนต์ที่ประมวลผลการตอบกลับแบบสาธารณะจึงยังคงทำงานได้ต่อเนื่องหลังจากที่คุณเปลี่ยนมาใช้เวอร์ชันที่ยืนยันตัวตนแล้ว — มีเพียงส่วนของการเรียกใช้งานเท่านั้นที่เปลี่ยนไป
• รองรับทั้ง X-API-KEY: {key} (แนะนำ, สอดคล้องกับ /apiv2/order1h) และ Authorization: Bearer {key} / Authorization: {key}; หากส่งมาทั้งสองแบบ ระบบจะใช้ X-API-KEY เป็นหลัก
• การสลับตัวกลางของ Cloudflare / reverse-proxy จะไม่ส่งผลกระทบต่อ endpoint นี้ในลักษณะเดียวกับที่กระทบต่อ endpoint สาธารณะ เนื่องจากทราฟฟิกที่ผ่านการยืนยันตัวตนแล้วจะถูกจำกัดอัตราการเรียกใช้งานต่อโหนด Kong และสามารถเปิดใช้งานข้อกำหนดเฉพาะตามแต่ละ consumer ได้ตามคำขอ