सप्रेशन
आपके वर्कस्पेस की एक सप्रेशन सूची होती है: ईमेल पतों का एक सेट जिन पर हम डिलीवरी नहीं करते। हार्ड बाउंस और स्पैम शिकायतें अपने आप इसमें जुड़ जाती हैं, और आप खुद भी पते जोड़ सकते हैं। बार-बार ऐसे पतों पर मेल भेजना जो बाउंस होते हैं या स्पैम रिपोर्ट करते हैं, मेलबॉक्स प्रदाताओं द्वारा आपके डोमेन को ब्लॉक करवा सकता है, इसलिए हम उन भेजावों को प्लेटफ़ॉर्म छोड़ने से पहले ही रोक देते हैं।
नया अनसब्सक्राइब करने पर सप्रेशन रिकॉर्ड नहीं बनता। यह डिलीवरेबिलिटी तथ्य नहीं बल्कि प्राप्तकर्ता की अपनी बताई प्राथमिकता दर्ज करता है, इसलिए यह Preferences टैब में रहता है। यह कैसे काम करता है, इसके लिए अनसब्सक्राइब लिंक देखें।
सूची को Email > Suppressions में, सप्रेशन API के ज़रिए, या bird email suppressions से प्रबंधित करें।
तीन कारण और वे क्या ब्लॉक करते हैं
हर रिकॉर्ड में एक reason होता है जो बताता है कि पता क्यों सूचीबद्ध है, और एक applies_to पॉलिसी होती है जो नियंत्रित करती है कि यह कौन-सी श्रेणियाँ ब्लॉक करता है:
| कारण | applies_to | मार्केटिंग श्रेणी | ट्रांज़ैक्शनल श्रेणी |
|---|---|---|---|
| hard_bounce | all | ब्लॉक्ड | ब्लॉक्ड |
| complaint | non_transactional | ब्लॉक्ड | अनुमत |
| manual | all | ब्लॉक्ड | ब्लॉक्ड |
यह विभाजन हर कारण के अर्थ से निकलता है:
- hard_bounce: पता मौजूद नहीं है। किसी भी श्रेणी में भेजना व्यर्थ है, इसलिए यह सब कुछ ब्लॉक करता है।
- complaint: अनचाहे मेल के बारे में एक बयान। जिसने आपका न्यूज़लेटर स्पैम के रूप में रिपोर्ट किया, उसे अभी भी पासवर्ड रीसेट या ऑर्डर कन्फ़र्मेशन की ज़रूरत हो सकती है, इसलिए यह केवल गैर-ट्रांज़ैक्शनल भेजावों को ब्लॉक करता है।
- manual: आपका या आपकी टीम का एक जानबूझकर लिया गया निर्णय। हम इस पर सवाल नहीं उठाते, इसलिए मैन्युअल सप्रेशन ट्रांज़ैक्शनल सहित हर श्रेणी को ब्लॉक करता है।
एक पते पर प्रति कारण एक रिकॉर्ड होता है, इसलिए एक हार्ड बाउंस और पहले की कोई शिकायत अलग-अलग रिकॉर्ड के रूप में साथ-साथ रहते हैं, और जब तक कोई भी ब्लॉक करने वाला रिकॉर्ड मौजूद है, डिलीवरी ब्लॉक रहती है। हम किसी भी अपरिचित चीज़ पर fail closed करते हैं: यदि कोई रिकॉर्ड ऐसे applies_to के साथ आता है जो आपके इंटीग्रेशन ने कभी नहीं देखा, तो उसे हर श्रेणी को ब्लॉक करने वाला मानें, क्योंकि हम खुद भी इसे ऐसे ही मानते हैं।
Note: reason: unsubscribe is deprecated on the suppressions API. New unsubscribes record a preference instead of a suppression. The deprecated ?reason=unsubscribe filter still returns legacy suppression records with origin: unsubscribe_link or origin: unsubscribe_event until those records are removed.
पते स्वचालित रूप से कैसे जोड़े जाते हैं
हम प्राप्तकर्ता सिग्नलों के जवाब में सप्रेशन जोड़ते हैं, इसलिए बाउंस या शिकायत के लिए आपको कुछ करने की ज़रूरत नहीं:
| ट्रिगर | परिणामी सप्रेशन |
|---|---|
| हार्ड बाउंस (email.bounced) | reason: hard_bounce, origin: bounce_event, applies_to: all |
| आउट-ऑफ़-बैंड हार्ड बाउंस (email.out_of_band_bounce) | reason: hard_bounce, origin: bounce_event, applies_to: all |
| स्पैम शिकायत (email.complained) | reason: complaint, origin: complaint_event, applies_to: non_transactional |
अनसब्सक्राइब, चाहे इन-बॉडी लिंक या वन-क्लिक बटन के ज़रिए हो, यहाँ दिखाई नहीं देता: यह इस सूची में पंक्ति जोड़ने के बजाय Preferences टैब पर प्राथमिकता दर्ज करता है।
केवल hard-क्लास बाउंस ही सप्रेस करता है, और वर्गीकरण तालिका दिखाती है कि कौन-से bounce_class मान hard माने जाते हैं। दो परिणाम जो विफलता जैसे दिखते हैं, पते को भेजने योग्य छोड़ देते हैं:
- सॉफ़्ट बाउंस और डिफ़रल (email.deferred, या email.bounced के साथ bounce_type: "soft"): क्षणिक विफलताएँ जैसे भरा हुआ मेलबॉक्स। हम फिर से प्रयास करते हैं।
- सेंड-साइड रिजेक्शन: जनरेशन विफलताएँ और पॉलिसी रिजेक्शन भेजने की समस्याएँ हैं, पते की नहीं। ये email.rejected इवेंट उत्पन्न करते हैं और कोई सप्रेशन नहीं।
उसी कारण से पहले से सप्रेस किए गए पते के लिए दोहराए गए सिग्नल मूल रिकॉर्ड को उसके created_at सहित अपरिवर्तित छोड़ देते हैं। रिकॉर्ड में source_email_id और source_recipient_id रहते हैं, जो एक स्वचालित सप्रेशन को उस सटीक संदेश और प्राप्तकर्ता से जोड़ते हैं जिसने इसे उत्पन्न किया। ये दोनों फ़ील्ड सपोर्ट प्रश्न "why did this person stop getting our email" का उत्तर देते हैं, और मैन्युअल जोड़ पर ये null होते हैं।
हर जोड़, स्वचालित या मैन्युअल, आपके webhook एंडपॉइंट पर एक email_suppression.created इवेंट फ़ायर करता है जिसमें suppression_id, सप्रेस किया गया email, reason, और workspace_id शामिल होते हैं, ताकि आपका अपना सिस्टम पोलिंग के बिना सूची को मिरर कर सके:
कोड उदाहरण
{
"type": "email_suppression.created",
"timestamp": "2026-07-23T14:52:03.192524705Z",
"data": {
"email": "user@example.com",
"reason": "manual",
"suppression_id": "sup_01ky7qckqrf06r38g49b9kxdbc",
"workspace_id": "ws_01ky7m21hjffh9s8kq76gyb1xf"
}
}API के ज़रिए सप्रेशन प्रबंधित करना
API एकल रिकॉर्ड जोड़ता, सूचीबद्ध करता, खोजता और हटाता है। पते स्टोरेज और लुकअप से पहले लोअरकेस किए जाते हैं, और वे कभी URL पथ में दिखाई नहीं देते, क्योंकि पथ एक्सेस लॉग में आता है और ईमेल पता व्यक्तिगत डेटा है। किसी पते का रिकॉर्ड खोजने के लिए, सूची को ?email= से फ़िल्टर करें।
हर SDK इन ऑपरेशन्स को अपने suppressions रिसोर्स पर टाइप्ड मेथड्स के रूप में उपलब्ध कराता है।
पता जोड़ें
const suppression = await bird.suppressions.add({ email: "user@example.com" });
console.log(suppression.id);suppression = client.suppressions.add(email="user@example.com")
print(suppression.id)suppression, err := client.Suppressions.Add(context.Background(), bird.SuppressionsAddParams{
Email: "user@example.com",
})
if err != nil {
log.Fatal(err)
}
fmt.Println(suppression.Id)$suppression = $bird->suppressions->add(
(new SuppressionCreate())->setEmail('user@example.com'),
);
echo $suppression->getId();bird email suppressions add --email user@example.comcurl -X POST https://us1.platform.bird.com/v1/email/suppressions \
-H "Authorization: Bearer $BIRD_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "email": "user@example.com" }'मैन्युअल जोड़ में reason: manual और applies_to: all मिलते हैं, इसलिए वे हर श्रेणी को ब्लॉक करते हैं। कॉल idempotent है: एक नया सप्रेशन 201 Created लौटाता है, और पहले से मैन्युअली सप्रेस किया गया पता conflict के बजाय मौजूदा रिकॉर्ड के साथ 200 OK लौटाता है। दोनों स्थितियों में बॉडी सप्रेशन ऑब्जेक्ट होती है:
कोड उदाहरण
{
"applies_to": "all",
"created_at": "2026-07-23T14:52:03.192524705Z",
"email": "user@example.com",
"id": "sup_01ky7qckqrf06r38g49b9kxdbc",
"origin": "api_key",
"reason": "manual",
"scope": {
"id": "ws_01ky7m21hjffh9s8kq76gyb1xf",
"type": "workspace"
}
}origin फ़ील्ड दर्ज करता है कि रिकॉर्ड कैसे बना। मैन्युअल जोड़ में api_key या user मिलता है, इस पर निर्भर करते हुए कि कॉलर ने API key से प्रमाणित किया या डैशबोर्ड सेशन से। स्वचालित जोड़ में bounce_event या complaint_event मिलता है, इस पर निर्भर करते हुए कि किस सिग्नल ने इसे बनाया।
सूचीबद्ध करें और खोजें
ये कॉल्स पहला पेज लौटाती हैं। Go में, खाली तीसरा आर्गुमेंट पेजिनेशन शुरू करता है; अगला पेज पढ़ने के लिए पिछले पेज का NextCursor पास करें।
const page = await bird.suppressions.list({ limit: 25 });
console.log(page.data.length);page = client.suppressions.list(limit=25)
print(len(page.data))page, err := client.Suppressions.ListPage(context.Background(), bird.SuppressionsListParams{Limit: 25}, "")
if err != nil {
log.Fatal(err)
}
fmt.Println(len(page.Data))$page = $bird->suppressions->list(['limit' => 25])->fetch();
echo count($page->data);bird email suppressions list --limit 25curl "https://us1.platform.bird.com/v1/email/suppressions?limit=25" \
-H "Authorization: Bearer $BIRD_API_KEY"सूची कर्सर-पेजिनेटेड है, नवीनतम पहले, और reason द्वारा फ़िल्टर करने योग्य है। किसी एक पते की जाँच करने के लिए इसे email क्वेरी पैरामीटर के रूप में पास करें:
const page = await bird.suppressions.list({ email: "user@example.com" });
console.log(page.data.length);page = client.suppressions.list(email="user@example.com")
print(len(page.data))page, err := client.Suppressions.ListPage(context.Background(), bird.SuppressionsListParams{
Email: "user@example.com",
}, "")
if err != nil {
log.Fatal(err)
}
fmt.Println(len(page.Data))$page = $bird->suppressions->list(['email' => 'user@example.com'])->fetch();
echo count($page->data);bird email suppressions list --email user@example.comcurl "https://us1.platform.bird.com/v1/email/suppressions?email=user@example.com" \
-H "Authorization: Bearer $BIRD_API_KEY"email फ़िल्टर प्रीफ़िक्स द्वारा केस-असंवेदनशील रूप से मैच करता है: user@example.com भी user@example.com.au से मैच करता है। हर लौटाए गए पते की तुलना आपके अनुरोधित पूरे पते से करें, और मैचिंग रिकॉर्ड मौजूद है या नहीं यह तय करने से पहले हर पेज में next_cursor को फ़ॉलो करें। एक पते पर कई रिकॉर्ड लागू हो सकते हैं। MCP कॉलर इस सटीक-पता लुकअप के लिए email_suppressions_check का उपयोग कर सकते हैं।
जब आपके पास सप्रेशन ID हो, तो GET /v1/email/suppressions/{suppression_id} वह एक रिकॉर्ड लौटाता है: SDKs में suppressions.get, या CLI पर bird email suppressions get <id>।
पता हटाएँ
await bird.suppressions.remove("sup_01ky7qckqrf06r38g49b9kxdbc");client.suppressions.remove("sup_01ky7qckqrf06r38g49b9kxdbc")if err := client.Suppressions.Remove(context.Background(), "sup_01ky7qckqrf06r38g49b9kxdbc"); err != nil {
log.Fatal(err)
}$bird->suppressions->remove('sup_01ky7qckqrf06r38g49b9kxdbc');bird email suppressions remove sup_01ky7qckqrf06r38g49b9kxdbc --yescurl -X DELETE https://us1.platform.bird.com/v1/email/suppressions/sup_01ky7qckqrf06r38g49b9kxdbc \
-H "Authorization: Bearer $BIRD_API_KEY"एक कारण को इस तरह नहीं हटाया जा सकता। complaint रिकॉर्ड केवल साइन-इन किए हुए डैशबोर्ड उपयोगकर्ता के लिए हटता है; API की को 422 SuppressionNotRemovableByAPIKey मिलता है। hard_bounce और manual रिकॉर्ड दोनों तरीकों से हटाए जा सकते हैं।
204 No Content लौटाता है और उस रिकॉर्ड को स्थायी रूप से हटा देता है। उसी पते के अन्य रिकॉर्ड बने रहते हैं, और जब तक कोई शेष रिकॉर्ड मैसेज कैटेगरी को ब्लॉक करता है, डिलीवरी ब्लॉक रहती है। पते के आधार पर रिकॉर्ड हटाने के लिए, ?email= लुकअप को पेजिनेट करें, केवल पूरे-पते के मैच चुनें, और हर इच्छित रिकॉर्ड को ID से डिलीट करें। hard_bounce रिकॉर्ड हटाते समय सोच-समझकर काम करें, क्योंकि जो पता अभी भी मौजूद नहीं है वह अगले भेजने पर बाउंस होगा और खुद को फिर से सप्रेस कर लेगा।
सप्रेस किए गए पते पर भेजने पर क्या होता है
हम प्राप्तकर्ता को वहाँ रिजेक्ट करते हैं जहाँ आप देख सकें। प्राप्तकर्ता को recipient_id मिलता है और वह मैसेज की प्राप्तकर्ता सूची में rejected स्टेटस के साथ दिखाई देता है। इवेंट्स API और आपके webhooks एक email.rejected इवेंट को rejection_reason: "recipient_suppressed" के साथ रिकॉर्ड करते हैं। बाकी प्राप्तकर्ता सामान्य रूप से डिलीवर होते हैं।
मैसेज स्वयं 202 के साथ स्वीकार किया जाता है, भले ही उसके सभी प्राप्तकर्ता सप्रेस हों। हम सेंड स्वीकार करने के बाद, मैसेज प्रोसेस करते समय सप्रेशन रिज़ॉल्व करते हैं, इसलिए अभी जोड़ा गया पता कुछ ही मिनटों में लागू हो जाता है और पहले से चल रहे किसी सेंड को नहीं रोकता।
सैंडबॉक्स के साथ परीक्षण
टेस्टिंग सैंडबॉक्स सप्रेशन हैंडलिंग को नियतात्मक रूप से चलाता है। suppressed@messagebird.dev पर भेजने पर ऐसा व्यवहार होता है जैसे पता आपकी सूची में हो: प्राप्तकर्ता rejection_reason: "recipient_suppressed" के साथ रिजेक्ट होता है और डिलीवरी तक कभी नहीं पहुँचता। सैंडबॉक्स बाउंस और कंप्लेंट पते (bounce@messagebird.dev, complaint@messagebird.dev) अपने परिणामों को वास्तविक इवेंट पाइपलाइन से गुज़ारते हैं लेकिन आपकी सप्रेशन सूची में कुछ नहीं लिखते, इसलिए वही टेस्ट पते हर रन में दोबारा उपयोग किए जा सकते हैं।
अगले कदम
- कैटेगरीज़: transactional बनाम marketing, और कैटेगरी सप्रेशन पॉलिसी के साथ कैसे इंटरैक्ट करती है
- अनसब्सक्राइब लिंक: ऑप्ट-आउट सप्रेशन के बजाय बताई गई प्राथमिकता कैसे दर्ज करते हैं
- इवेंट्स और webhooks: email.rejected पेलोड और लाइफ़साइकल इवेंट्स जो स्वचालित सप्रेशन को चलाते हैं
- टेस्टिंग सैंडबॉक्स: हर डिलीवरी परिणाम को सिमुलेट करने के लिए मैजिक पते
- API reference: Suppressions: पूर्ण अनुरोध और प्रतिक्रिया स्कीमा
- जब कोई ऑप्ट आउट करता है तो क्या होता है: एक वीडियो जो एक प्राप्तकर्ता को अनसब्सक्राइब पेज से रिजेक्टेड सेंड तक फ़ॉलो करता है
संबंधित संसाधन
इस विषय के लिए डॉक्यूमेंटेशन, गाइड और उदाहरणों के साथ आगे बढ़ें। संसाधन अंग्रेज़ी में हैं।
कॉन्सेप्ट समझेंWhat is one-click unsubscribe, and how do I implement List-Unsubscribe?क्षमता जानेंEmail opt-outsलर्निंग पाथ फ़ॉलो करेंOperate messaging reliably
इम्प्लीमेंटेशन ब्रीफ़ पाएँ