वेबहुक — ऑर्डर सूचनाएं

आपके ऑर्डरों में से किसी एक के पूरा होने और ऑन-चेन सत्यापित होने के तुरंत बाद एक हस्ताक्षरित वेबहुक प्राप्त करने के लिए एक HTTPS एंडपॉइंट पंजीकृत करें। पोलिंग करने के बजाय, सूचना मिलते ही आप अपना प्रवाह जारी रख सकते हैं (उदा. USDT जारी करना)।

तीन इवेंट वितरित किए जाते हैं:

इवेंट	कब भेजा जाता है
`delegation.confirmed`	जब एक energy रेंटल (`1h` / `5m`) ऑन-चेन कन्फर्म हो जाता है
`bandwidth.delegated`	जब एक bandwidth ऑर्डर पूरा हो जाता है
`activation.confirmed`	जब एक एड्रेस एक्टिवेशन ऑन-चेन निष्पादित हो जाता है

यह पृष्ठ प्रबंधन API (अपने एंडपॉइंट्स को बनाना / सूचीबद्ध करना / संपादित करना / सीक्रेट रोटेट करना / हटाना) और हमारे द्वारा आपको वितरित किए जाने वाले वेबहुक के प्रारूप को कवर करता है।

ℹ️ भूमिकाएं। आप अपने एंडपॉइंट्स का प्रबंधन यहां करते हैं। ऑर्डर सत्यापित होने के बाद Netts द्वारा डिलीवरी एसिंक्रोनस रूप से की जाती है — पोल करने के लिए कुछ भी नहीं है। केवल सफल इवेंट ही भेजे जाते हैं; विफलताओं और टाइमआउट को कभी भी वितरित नहीं किया जाता है।

🔒 हमारे द्वारा भेजा जाने वाला प्रत्येक हैश पहले ऑन-चेन सत्यापित होता है। एक वेबहुक केवल तभी भेजा जाता है जब उसमें मौजूद प्रत्येक लेनदेन हैश एक ब्लॉक में मिल जाता है। यदि कोई हैश अभी तक ब्लॉक में नहीं है, तो डिलीवरी रोक दी जाती है और 5 मिनट तक हर 30 सेकंड में पुन: जांची जाती है; यदि यह कभी ब्लॉक में नहीं आता है, तो उस ऑर्डर के लिए कुछ भी नहीं भेजा जाता है। आपको कभी भी ऐसा हैश प्राप्त नहीं होगा जो ऑन-चेन मौजूद न हो।

एंडपॉइंट बेस URL

https://netts.io/apiv2/webhooks

अनुरोध हेडर

हेडर	आवश्यक	विवरण
Content-Type	हाँ (POST/PATCH के लिए)	application/json
X-API-KEY	हाँ	Netts डैशबोर्ड से आपकी API कुंजी
X-Real-IP	हाँ	आपकी श्वेतसूची (व्हाइटलिस्ट) से IP पता

आपकी user_id API कुंजी से प्राप्त होती है — आपको इसे कभी पास करने की आवश्यकता नहीं होती है। आप केवल अपने स्वयं के एंडपॉइंट्स को देख और संशोधित कर सकते हैं।

प्राथमिक और बैकअप एंडपॉइंट

आप अधिकतम दो एंडपॉइंट पंजीकृत कर सकते हैं, और प्रत्येक की एक role होती है:

भूमिका	उद्देश्य
`primary`	वह पता जहां प्रत्येक वेबहुक वितरित किया जाता है।
`backup`	फ़ॉलबैक। इसका उपयोग केवल तब किया जाता है जब पुनः प्रयासों के समाप्त होने के बाद `primary` पर डिलीवरी विफल हो जाती है।

एक एकल पुष्ट ऑर्डर एक एकल वेबहुक उत्पन्न करता है। यह फ़ैन-आउट नहीं है: एक ही इवेंट को कभी भी दोनों पतों पर एक साथ नहीं भेजा जाता है। backup एंडपॉइंट लचीलेपन के लिए मौजूद है — यदि आपका प्राथमिक होस्ट अगम्य है या गैर-2xx लौटाता रहता है, तो डिलीवरी ड्रॉप होने के बजाय बैकअप पर स्थानांतरित हो जाती है।

आपके द्वारा बनाया गया पहला एंडपॉइंट primary बन जाता है, दूसरा backup बन जाता है। आप स्पष्ट रूप से role पास कर सकते हैं, या बाद में PATCH के साथ उन्हें आपस में बदल सकते हैं।

प्रति ऑपरेशन प्रकार एक अलग URL क्यों नहीं? क्योंकि इवेंट का प्रकार event फ़ील्ड में, बॉडी के अंदर भेजा जाता है। एक हैंडलर, एक सिग्नेचर जांच, और आपको कुछ भी नया पंजीकृत किए बिना नए प्रकार के इवेंट प्राप्त होने लगते हैं।

एंडपॉइंट्स प्रबंधित करें

बनाएं — `POST /apiv2/webhooks`

एक नया एंडपॉइंट पंजीकृत करता है और केवल एक बार दिखाया जाने वाला secret लौटाता है (इसे संग्रहीत करें — यह आपको प्राप्त होने वाले प्रत्येक वेबहुक पर हस्ताक्षर करता है)।

json

// request body — role is optional
{
    "url": "https://your-server.example/netts/delegation-hook",
    "role": "primary"
}

यदि आप role छोड़ देते हैं, तो पहली खाली भूमिका असाइन की जाती है: पहले primary, फिर backup।

json

// response 201
{
    "detail": {
        "code": 10000,
        "status": "created",
        "data": {
            "id": 1,
            "url": "https://your-server.example/netts/delegation-hook",
            "secret": "whsec_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
            "role": "primary",
            "is_active": true,
            "created_at": "2026-01-01T00:00:00"
        }
    }
}

URL आवश्यकताएं (निर्माण पर और प्रत्येक संपादन पर मान्य की जाती हैं):

https होना चाहिए;
सार्वजनिक पते पर रिज़ॉल्व होना चाहिए — लूपबैक, निजी (RFC1918), लिंक-लोकल (169.254.169.254 सहित), और अन्य गैर-रूट करने योग्य श्रेणियां अस्वीकार कर दी जाती हैं;
URL में कोई क्रेडेंशियल नहीं होना चाहिए (user:pass@…);
लंबाई अधिकतम 2048 वर्ण।

अस्वीकृत URL 400 लौटाता है।

आपके पास दो एंडपॉइंट हो सकते हैं — एक primary और एक backup। तीसरा एंडपॉइंट 409 (4090) लौटाता है। पहले से ली जा चुकी role का अनुरोध करने पर 409 (4091) प्राप्त होता है — भूमिकाओं को PATCH के साथ बदलें या पहले मौजूदा एंडपॉइंट को हटाएं।

bash

curl -X POST https://netts.io/apiv2/webhooks \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: your_api_key" \
  -H "X-Real-IP: your_whitelisted_ip" \
  -d '{"url": "https://your-server.example/netts/delegation-hook", "role": "primary"}'

सूची — `GET /apiv2/webhooks`

आपके एंडपॉइंट्स लौटाता है (secret यहां कभी नहीं लौटाया जाता है)।

json

{
    "detail": {
        "code": 10000,
        "status": "ok",
        "data": {
            "endpoints": [
                {
                    "id": 1,
                    "url": "https://your-server.example/netts/delegation-hook",
                    "role": "primary",
                    "is_active": true,
                    "created_at": "2026-01-01T00:00:00",
                    "updated_at": "2026-01-01T00:00:00"
                },
                {
                    "id": 2,
                    "url": "https://backup.example/netts/delegation-hook",
                    "role": "backup",
                    "is_active": true,
                    "created_at": "2026-01-01T00:00:00",
                    "updated_at": "2026-01-01T00:00:00"
                }
            ],
            "count": 2,
            "max_endpoints": 2,
            "roles": ["primary", "backup"]
        }
    }
}

एक प्राप्त करें — `GET /apiv2/webhooks/{id}`

सूची आइटम के समान प्रारूप (कोई secret नहीं)। एक अज्ञात या गैर-मौजूद id 404 लौटाता है।

संपादित करें — `PATCH /apiv2/webhooks/{id}`

url, is_active और/या role बदलें। कोई भी सबसेट भेजें; एक खाली बॉडी 422 लौटाती है। एक परिवर्तित url को फिर से मान्य किया जाता है (https / SSRF)। एक अज्ञात या गैर-मौजूद id 404 लौटाता है।

json

// request body (any subset)
{ "url": "https://your-server.example/netts/new-hook", "is_active": false }

json

// response 200
{
    "detail": {
        "code": 10000,
        "status": "updated",
        "data": {
            "id": 1,
            "url": "https://your-server.example/netts/new-hook",
            "role": "primary",
            "is_active": false,
            "created_at": "2026-01-01T00:00:00",
            "updated_at": "2026-01-01T00:00:01"
        }
    }
}

बैकअप को प्रमोट करना। अपने बैकअप एंडपॉइंट पर {"role": "primary"} भेजने से एक ही लेनदेन में दोनों भूमिकाएं आपस में बदल जाती हैं — पुराना प्राथमिक बैकअप बन जाता है। आप कभी भी बिना किसी प्राथमिक पते के नहीं रहते हैं, और दूसरे एंडपॉइंट के लिए किसी अलग कॉल की आवश्यकता नहीं होती है।

bash

curl -X PATCH https://netts.io/apiv2/webhooks/2 \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: your_api_key" \
  -H "X-Real-IP: your_whitelisted_ip" \
  -d '{"role": "primary"}'

एंडपॉइंट को हटाए बिना डिलीवरी को रोकने के लिए is_active: false सेट करें; फिर से शुरू करने के लिए true सेट करें। अपने primary को रोकने से बैकअप का प्रमोशन नहीं होता है — डिलीवरी अभी भी प्राथमिक को लक्षित करती है। यदि आप चाहते हैं कि बैकअप कार्यभार संभाले तो भूमिकाओं को आपस में बदलें।

सीक्रेट रोटेट करें — `POST /apiv2/webhooks/{id}/rotate-secret`

एक नया secret उत्पन्न करता है और इसे एक बार लौटाता है। नया सीक्रेट बाद की डिलीवरी के लिए तुरंत प्रभावी हो जाता है — आगे किसी कार्रवाई की आवश्यकता नहीं है। प्रत्येक एंडपॉइंट का अपना स्वयं का सीक्रेट होता है: प्राथमिक के सीक्रेट को रोटेट करने से बैकअप का सीक्रेट नहीं बदलता है।

json

// response 200
{
    "detail": {
        "code": 10000,
        "status": "rotated",
        "data": {
            "id": 1,
            "secret": "whsec_yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
        }
    }
}

हटाएं — `DELETE /apiv2/webhooks/{id}`

एंडपॉइंट को स्थायी रूप से हटाता है और इसकी भूमिका को मुक्त करता है। 204 लौटाता है (कोई बॉडी नहीं); एक अज्ञात या गैर-मौजूद id 404 लौटाता है।

bash

curl -X DELETE https://netts.io/apiv2/webhooks/1 \
  -H "X-API-KEY: your_api_key" -H "X-Real-IP: your_whitelisted_ip"

हमारे द्वारा वितरित किए जाने वाले वेबहुक

जब आपका कोई ऑर्डर पूरा हो जाता है, तो Netts आपके primary एंडपॉइंट पर एक POST भेजता है। प्रत्येक बॉडी application/json (UTF-8) होती है; पते और हैश हमेशा पूर्ण मान होते हैं।

सभी इवेंट के लिए सामान्य फ़ील्ड:

फ़ील्ड	प्रकार	विवरण
`event`	string	इवेंट प्रकार — आपके हैंडलर के लिए रूटिंग कुंजी
`delivery_id`	int	डिलीवरी ID — आपकी ओर से डीडुप्लीकेशन (dedup) कुंजी। `X-Netts-Delivery` हेडर में भी भेजा जाता है।
`order_id`	string	आपकी ऑर्डर ID
`order_type`	string	`1h`, `5m`, `bandwidth` या `activation`
`tx_hashes`	string[]	ऑपरेशन के सभी लेन-देन हैश, प्रत्येक ऑन-चेन सत्यापित
`confirmed_at`	string	UTC ISO-8601

`delegation.confirmed` — energy रेंटल

json

{
    "event": "delegation.confirmed",
    "delivery_id": 1,
    "order_id": "1Hxxxxxxxxxx",
    "order_type": "1h",
    "receive_address": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "energy_amount": 65000,
    "tx_hash": "0000000000000000000000000000000000000000000000000000000000000000",
    "tx_hashes": ["0000000000000000000000000000000000000000000000000000000000000000"],
    "delegation_timestamp": 1700000000000,
    "confirmed_at": "2026-01-01T00:00:00Z"
}

फ़ील्ड	प्रकार	विवरण
`order_type`	string	`1h` या `5m`
`receive_address`	string	TRON पता जिसने energy प्राप्त की
`energy_amount`	int	डेलिगेट की गई Energy की मात्रा
`tx_hash`	string	लीगेसी फ़ील्ड, अनुकूलता के लिए रखी गई: `tx_hashes[0]` के समान
`delegation_timestamp`	int?	वैकल्पिक — केवल तभी उपस्थित जब Mongo पथ के माध्यम से पुष्टि की गई हो

नए एकीकरणों में tx_hashes को प्राथमिकता दें — एक ऑर्डर सैद्धांतिक रूप से एक से अधिक लेन-देन द्वारा पूरा किया जा सकता है। tx_hash काम करता रहेगा।

`bandwidth.delegated` — bandwidth ऑर्डर

json

{
    "event": "bandwidth.delegated",
    "delivery_id": 2,
    "order_id": "B1Hxxxxxxxxxxxxx",
    "order_type": "bandwidth",
    "rental_label": "1h",
    "rental_seconds": 3600,
    "receive_address": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "bandwidth_amount": 400,
    "fulfillment": "delegated",
    "tx_hashes": ["0000000000000000000000000000000000000000000000000000000000000000"],
    "confirmed_at": "2026-01-01T00:00:00Z"
}

फ़ील्ड	प्रकार	विवरण
`rental_label` / `rental_seconds`	string / int	रेंटल अवधि, उदा. `1h` / `3600`
`receive_address`	string	TRON पता जिसने bandwidth प्राप्त की
`bandwidth_amount`	int	Bandwidth इकाइयां (नेट)
`fulfillment`	string	ऑर्डर कैसे पूरा किया गया — नीचे देखें

fulfillment मान:

मान	अर्थ	`tx_hashes`
`delegated`	हमारे पूल से डेलिगेट की गई Bandwidth	1+ हैश
`trx_send`	डेलिगेट करने के बजाय पते पर TRX भेजकर पूरा किया गया	1+ हैश
`already_enough`	पते पर पहले से ही पर्याप्त मुफ्त bandwidth थी — ऑन-चेन कुछ भी नहीं भेजा गया था	खाली

already_enough ही एकमात्र ऐसा मामला है जहां tx_hashes खाली होता है: ऑर्डर सफलतापूर्वक बंद कर दिया जाता है, लेकिन कोई लेनदेन नहीं होता है क्योंकि किसी की आवश्यकता नहीं थी।

`activation.confirmed` — एड्रेस एक्टिवेशन

json

{
    "event": "activation.confirmed",
    "delivery_id": 3,
    "order_id": "123456",
    "order_type": "activation",
    "address": "TXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "activation_type": "ACC_CREATE",
    "source": "telegram_bot",
    "tx_hashes": ["0000000000000000000000000000000000000000000000000000000000000000"],
    "confirmed_at": "2026-01-01T00:00:00Z"
}

फ़ील्ड	प्रकार	विवरण
`order_id`	string	एक्टिवेशन ऑर्डर ID (संख्यात्मक स्ट्रिंग)
`address`	string	TRON पता जो सक्रिय किया गया था
`activation_type`	string	`ACC_CREATE` (AccountCreateContract) या `DIRECT` (TRX स्थानांतरण)
`source`	string	उत्पत्ति मार्कर। या तो एक सेवा टैग, या energy ऑर्डर की ID जिसके लिए एक्टिवेशन की आवश्यकता थी

केवल वास्तविक एक्टिवेशन ही वितरित किए जाते हैं। यदि पता पहले से ही सक्रिय निकला और कोई लेनदेन नहीं किया गया, तो कोई भी वेबहुक नहीं भेजा जाता है।

एक energy ऑर्डर जिसके लिए एक्टिवेशन की भी आवश्यकता थी, वह दो वेबहुक उत्पन्न करता है — एक activation.confirmed और एक delegation.confirmed। वे अलग-अलग delivery_id के साथ अलग-अलग इवेंट हैं; उन्हें event फ़ील्ड द्वारा रूट करें।

हमारे द्वारा भेजे जाने वाले हेडर:

हेडर	मान
`X-Netts-Event`	इवेंट प्रकार: `delegation.confirmed`, `bandwidth.delegated` या `activation.confirmed`
`X-Netts-Delivery`	`delivery_id` (डीडुप)
`X-Netts-Timestamp`	भेजने के समय unix सेकंड
`X-Netts-Signature`	`sha256=<hex>`, `hex = HMAC_SHA256(secret, "<timestamp>." + raw_body)`
`User-Agent`	`netts-webhook/1.0`

हस्ताक्षर सत्यापित करना

हस्ताक्षर Stripe योजना (timestamp.body) का अनुसरण करता है, जिसकी गणना हमारे द्वारा भेजे जाने वाले रॉ बाइट्स (raw bytes) पर की जाती है। अपने secret के साथ इसकी पुनर्गणना करें, कॉन्स्टेंट-टाइम की तुलना करें, और यदि X-Netts-Timestamp एक ±5 मिनट की विंडो के बाहर है तो इसे अस्वीकार करें (रीप्ले सुरक्षा)।

उस एंडपॉइंट के सीक्रेट के साथ हस्ताक्षर करें जिसने अनुरोध प्राप्त किया था: प्राथमिक और बैकअप के पास अलग-अलग सीक्रेट होते हैं। यदि आपके दोनों पते एक ही हैंडलर द्वारा संचालित होते हैं, तो उस URL के अनुसार सीक्रेट चुनें जिस पर अनुरोध आया था।

python

import hmac, hashlib, time

def verify(raw_body: bytes, sig_header: str, ts_header: str, secret: str) -> bool:
    # freshness (anti-replay)
    if abs(time.time() - int(ts_header)) > 300:
        return False
    signed = f"{ts_header}.".encode() + raw_body
    expected = "sha256=" + hmac.new(secret.encode(), signed, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, sig_header)

# Flask example:
# ok = verify(request.get_data(),
#             request.headers["X-Netts-Signature"],
#             request.headers["X-Netts-Timestamp"], SECRET)

डिलीवरी सिमेंटिक्स (महत्वपूर्ण — कम से कम एक बार)

डिलीवरी कम से कम एक बार (at-least-once) होती है: किसी ड्रॉप हुई प्रतिक्रिया के कारण पुनः प्रयास हो सकता है, इसलिए आपको एक ही इवेंट दो बार प्राप्त हो सकता है। चूंकि व्यावसायिक कार्रवाई (USDT जारी करना) वित्तीय रूप से संवेदनशील है:

डीडुप्लीकेशन अनिवार्य है — delivery_id (और/या order_id) द्वारा प्रत्येक इवेंट को निष्क्रिय रूप से (idempotently) संसाधित करें; दोहराव पर कोई कार्रवाई न करें (no-op)।
किसी भी वित्तीय कार्रवाई से पहले HMAC सत्यापित करें — जब तक हस्ताक्षर मेल न खाए और X-Netts-Timestamp नया न हो, बॉडी पर भरोसा न करें।
इवेंट को स्थायी रूप से संग्रहीत करने के बाद ही 2xx लौटाएं — अन्यथा हम (सही ढंग से) पुनः प्रयास करते हैं।

स्वीकार करने के लिए 2xx उत्तर दें; कोई भी गैर-2xx / टाइमआउट एक पुनः प्रयास को ट्रिगर करता है।

प्रयासों का क्रम:

पुनः प्रयास आपके primary एंडपॉइंट पर जाते हैं। विंडो ऑर्डर के प्रकार पर निर्भर करती है: 5m ऑर्डर ~1 मिनट के लिए पुनः प्रयास करते हैं, अन्य सभी प्रकार ~10 मिनट के लिए।
यदि विंडो समाप्त हो जाती है और आपने एक backup पंजीकृत किया है, तो डिलीवरी वहां स्थानांतरित हो जाती है और पुनः प्रयास शेड्यूल फिर से शुरू होता है — बैकअप के अपने सीक्रेट के साथ हस्ताक्षरित।
बैकअप के भी समाप्त हो जाने के बाद ही डिलीवरी को निरस्त (dead) चिह्नित किया जाता है।

पूरे समय एक ही delivery_id का उपयोग किया जाता है, इसलिए एक संदेश जो पहले प्राथमिक पर विफल रहा और फिर बैकअप पर सफल रहा, वह आपके डीडुप लॉजिक के लिए अभी भी एक इवेंट है।

त्रुटि कोड संदर्भ

कोड	विवरण	HTTP स्थिति
`10000`	सफलता (created / ok / updated / rotated)	200 / 201
`-`	हटाया गया (कोई बॉडी नहीं)	204
`4000`	अमान्य / असुरक्षित वेबहुक URL (https नहीं, निजी/लूपबैक, क्रेडेंशियल, बहुत लंबा)	400
`-1`	अमान्य API कुंजी / IP श्वेतसूची में नहीं है	401
`-1`	एंडपॉइंट नहीं मिला (या आपका नहीं है)	404
`4090`	एंडपॉइंट सीमा समाप्त (अधिकतम 2: प्राथमिक, बैकअप)	409
`4091`	अनुरोधित भूमिका पहले ही ली जा चुकी है — `PATCH` के साथ बदलें या मौजूदा एंडपॉइंट हटाएं	409
`4220`	अपडेट करने के लिए कुछ भी नहीं है (खाली बॉडी के साथ PATCH)	422
`5003`	एंडपॉइंट बनाने में विफल (पुनः प्रयास करें)	503

दर सीमाएं (रेट लिमिट्स)

प्रति API कुंजी सीमित (हेडर X-API-KEY):

अवधि	सीमा
1 सेकंड	5 अनुरोध
1 मिनट	150 अनुरोध

दर सीमा पार हो गई (429)

json

{ "message": "API rate limit exceeded" }

नोट्स

सीक्रेट केवल एक बार दिखाया जाता है — निर्माण पर और रोटेट करने पर। यह GET/LIST द्वारा कभी नहीं लौटाया जाता है। खो गया? नया प्राप्त करने के लिए रोटेट करें।
दो एंडपॉइंट, फ़ैन-आउट नहीं: एक primary और एक backup। प्रत्येक पुष्ट ऑर्डर एक वेबहुक उत्पन्न करता है, जो प्राथमिक को वितरित किया जाता है; बैकअप का उपयोग केवल तभी किया जाता है जब प्राथमिक समाप्त हो जाता है।
शून्य-डाउनटाइम URL परिवर्तन: नए पते को backup के रूप में पंजीकृत करें, इसे सत्यापित करें, फिर इसे primary पर PATCH करें — यह अदला-बदली तात्कालिक (atomic) होती है।
रोकना: PATCH … {"is_active": false} एंडपॉइंट को खोए बिना डिलीवरी बंद कर देता है।
केवल सफलता इवेंट: delegation.confirmed, bandwidth.delegated, activation.confirmed। कोई विफलता इवेंट नहीं है — एक विफल या टाइम-आउट ऑर्डर कोई वेबहुक उत्पन्न नहीं करता है।
समय के साथ नए प्रकार के इवेंट जोड़े जा सकते हैं। event फ़ील्ड द्वारा रूट करें और उन प्रकारों पर ध्यान न दें जिन्हें आप अभी तक हैंडल नहीं करते हैं — उन्हें प्राप्त करना शुरू करने के लिए आपको कभी भी कुछ नया पंजीकृत करने की आवश्यकता नहीं है।
डिलीवरी से पहले ऑन-चेन हैश सत्यापित किए जाते हैं (शीर्ष पर नोट देखें): एक वेबहुक या तो ऐसे हैश रखता है जो सभी एक ब्लॉक में होते हैं, या बिल्कुल भी नहीं भेजा जाता है।
पंजीकरण के समय और प्रत्येक संपादन पर SSRF सुरक्षा के लिए URL मान्य किए जाते हैं; डिलीवरी पक्ष भेजने के समय फिर से पुष्टि करता है।

वेबहुक — ऑर्डर सूचनाएं ​

एंडपॉइंट बेस URL ​

अनुरोध हेडर ​

प्राथमिक और बैकअप एंडपॉइंट ​

एंडपॉइंट्स प्रबंधित करें ​

बनाएं — POST /apiv2/webhooks ​

सूची — GET /apiv2/webhooks ​

एक प्राप्त करें — GET /apiv2/webhooks/{id} ​

संपादित करें — PATCH /apiv2/webhooks/{id} ​

सीक्रेट रोटेट करें — POST /apiv2/webhooks/{id}/rotate-secret ​

हटाएं — DELETE /apiv2/webhooks/{id} ​

हमारे द्वारा वितरित किए जाने वाले वेबहुक ​

delegation.confirmed — energy रेंटल ​

bandwidth.delegated — bandwidth ऑर्डर ​

activation.confirmed — एड्रेस एक्टिवेशन ​

हस्ताक्षर सत्यापित करना ​

डिलीवरी सिमेंटिक्स (महत्वपूर्ण — कम से कम एक बार) ​

त्रुटि कोड संदर्भ ​

दर सीमाएं (रेट लिमिट्स) ​

दर सीमा पार हो गई (429) ​

नोट्स ​

वेबहुक — ऑर्डर सूचनाएं

एंडपॉइंट बेस URL

अनुरोध हेडर

प्राथमिक और बैकअप एंडपॉइंट

एंडपॉइंट्स प्रबंधित करें

बनाएं — `POST /apiv2/webhooks`

सूची — `GET /apiv2/webhooks`

एक प्राप्त करें — `GET /apiv2/webhooks/{id}`

संपादित करें — `PATCH /apiv2/webhooks/{id}`

सीक्रेट रोटेट करें — `POST /apiv2/webhooks/{id}/rotate-secret`

हटाएं — `DELETE /apiv2/webhooks/{id}`

हमारे द्वारा वितरित किए जाने वाले वेबहुक

`delegation.confirmed` — energy रेंटल

`bandwidth.delegated` — bandwidth ऑर्डर

`activation.confirmed` — एड्रेस एक्टिवेशन

हस्ताक्षर सत्यापित करना

डिलीवरी सिमेंटिक्स (महत्वपूर्ण — कम से कम एक बार)

त्रुटि कोड संदर्भ

दर सीमाएं (रेट लिमिट्स)

दर सीमा पार हो गई (429)

नोट्स