---
title: सुरक्षा
description: IDCloud webhook पेलोड को सत्यापित और सुरक्षित करने का तरीका — हस्ताक्षर सत्यापन और सर्वोत्तम प्रथाएं।
canonical: https://developer.unico.io/hi/dual-api/developers/webhooks-and-events/security
locale: hi
generated_by: markdown-export
---

Webhook की विश्वसनीयता आपके endpoint के व्यवहार पर उतनी ही निर्भर करती है जितनी Unico की delivery गारंटी पर। यह पृष्ठ तीन अपरिवर्तनीय सिद्धांतों को कवर करता है जिनका आपके endpoint को पालन करना होगा: **idempotency**, **concurrency limit**, और **error rate**।

### Idempotency

Unico का webhook implementation **at-least-once delivery** की गारंटी देता है — एक ही `processId` के लिए एक ही status एक से अधिक बार notify किया जा सकता है। आपका endpoint **अवश्य** idempotent होना चाहिए।

अनुशंसित pattern:

1. प्रत्येक webhook call पर, पहले जाँचें कि `processId` पहले से process किया जा चुका है या नहीं।
2. यदि हाँ, तो `2xx` तुरंत return करें (काम पहले ही हो चुका है)।
3. यदि नहीं, तो अपना business logic लागू करें और यह तथ्य persist करें कि यह `processId` process किया गया था।

```javascript
// pseudo-code
async function handleWebhook(req, res) {
  const { processId } = req.body;

  if (await alreadyProcessed(processId)) {
    return res.status(200).end();
  }

  await applyBusinessLogic(req.body);
  await markAsProcessed(processId);
  return res.status(200).end();
}
```

:::warning[यह क्यों महत्वपूर्ण है]
एक non-idempotent endpoint जो प्रत्येक delivery पर business logic चलाता है (जैसे, कार्ड charge करना, email भेजना) retry होने पर कई बार fire होगा — और retries webhook delivery में सामान्य हैं, असाधारण नहीं।
:::

### Concurrency limit

उच्च-मात्रा अवधि के दौरान spikes से आपके endpoint की सुरक्षा के लिए, webhook पंजीकृत करते समय अधिकतम simultaneous in-flight deliveries की संख्या (अधिकतम: **500**) configure करें।

जब concurrency limit पहुँच जाती है, Unico अतिरिक्त deliveries को queue करता है और capacity उपलब्ध होने पर उन्हें process करता है। Retries के साथ मिलकर, इसका अर्थ है कि sustained spike नए webhooks के प्रभावी delivery time को बढ़ा सकता है।

### Error rate

Error rate (responses जो `200`–`299` range से बाहर हैं) हमेशा कम होनी चाहिए। यदि आपका endpoint बड़े पैमाने पर errors return करने लगता है, तो Unico **उस endpoint के लिए webhook throughput स्वचालित रूप से कम कर देता है**। Retry mechanism के साथ मिलकर, यह नए webhooks के execution time को काफी बढ़ा सकता है।

परिचालन मार्गदर्शन:

- अपनी तरफ से non-2xx responses monitor करें। अपने सामान्य baseline से ऊपर sustained error rates पर alert करें।
- अपने webhook handler को **critical path** के रूप में मानें — यह आपके stack की सबसे विश्वसनीय services में से एक होनी चाहिए।
- **नियोजित maintenance के लिए**, load balancer पर intake रोकना बेहतर है बजाय `503` return करने के। लगातार non-2xx responses — `503` सहित — ऊपर वर्णित स्वचालित throughput throttling को सक्रिय करते हैं; जब आपका endpoint पुनः ठीक हो जाता है, तो कम throughput आउटेज के दौरान queue हुए events की delivery में देरी करता है। बिना process किए events के लिए `200` return न करें।

### Status semantics

`state` और `lastEvent` values के set को evolvable configuration के रूप में मानें:

- केवल उन states / events पर react करें जिन्हें आप explicitly handle करते हैं।
- अज्ञात values log करें — उन पर error न करें।
- Major version change के बिना नए states जोड़े जा सकते हैं।