Email टेम्प्लेट

टेम्प्लेट एक सब्जेक्ट लाइन और एक email बॉडी है जिसे आप एक बार सेव करते हैं और कई बार भेजते हैं। बदलने वाले हिस्सों को आप {{ variable }} प्लेसहोल्डर के रूप में लिखते हैं, टेम्प्लेट प्रकाशित करते हैं, और फिर हर API कॉल में वही HTML पेस्ट करने की जगह slug से भेजते हैं। टेम्प्लेट आपके वर्कस्पेस से जुड़ा होता है।

Email > Templates में, /v1/email/templates के ज़रिए, bird CLI से, या MCP server के ज़रिए टेम्प्लेट बनाएँ और प्रबंधित करें। टाइप्ड मेथड email.templates के अंतर्गत TypeScript, Python, PHP, और Go SDKs में उपलब्ध हैं। पूरे request और response स्कीमा API reference में हैं। प्रकाशित टेम्प्लेट को सामान्य send endpoint से भेजें।

टेम्प्लेट में क्या होता है

हर टेम्प्लेट के दो नाम होते हैं, और दोनों अलग-अलग काम करते हैं:

slug वह नाम है जिससे आप टेम्प्लेट भेजते हैं, उदाहरण के लिए welcome-email। इसे आप टेम्प्लेट बनाते समय चुनते हैं और बाद में बदला नहीं जा सकता। एक slug में lowercase अक्षर, संख्याएँ, हाइफ़न और अंडरस्कोर हो सकते हैं, इसे अक्षर या संख्या से शुरू और समाप्त होना चाहिए, और यह अधिकतम 63 कैरेक्टर लंबा हो सकता है। दो प्रीफ़िक्स वर्जित हैं: bird_, जो हमारे बिल्ट-इन टेम्प्लेट के लिए आरक्षित है, और emt_, जो टेम्प्लेट ID का फ़ॉर्मैट है। डैशबोर्ड इस फ़ील्ड को Alias कहता है।
name एक फ़्री-टेक्स्ट डिस्प्ले लेबल है। यह डिफ़ॉल्ट रूप से slug होता है, और आप इसे कभी भी बदल सकते हैं। नाम से कुछ रिज़ॉल्व नहीं होता, इसलिए डिस्प्ले के लिए टेम्प्लेट का नाम बदलने से कभी कोई send नहीं टूटती।

इनके अलावा, टेम्प्लेट का एक स्थायी emt_ ID होता है, जो पूरी उम्र भर स्थिर रहता है। इसकी एक category भी होती है, या तो marketing या transactional, और एक ऑथरिंग source: html, आपके द्वारा दिया गया तैयार मार्कअप, वैकल्पिक रूप से Liquid से पर्सनलाइज़्ड। कैटेगरी और सोर्स दोनों टेम्प्लेट बनाते समय तय हो जाते हैं।

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

ड्राफ़्ट और प्रकाशित संस्करण

हर टेम्प्लेट का ठीक एक ड्राफ़्ट होता है, जो वह वर्किंग कॉपी है जिसे आप संपादित करते हैं। इसके अलावा कितने भी प्रकाशित संस्करण हो सकते हैं, हर एक क्रमांकित (1, 2, 3, आदि) और एक बार बनने के बाद कभी नहीं बदलता। संपादन ड्राफ़्ट को वहीं बदलता है। प्रकाशन वर्तमान ड्राफ़्ट का स्नैपशॉट लेता है, उसे अगले क्रमांकित संस्करण में बदलता है, और उस संस्करण को send के लिए सक्रिय करता है। ड्राफ़्ट स्वयं संपादन योग्य बना रहता है, ताकि आप अगले पर काम जारी रख सकें।

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

Draft पंक्ति और प्रकाशित v3, v2, v1 पंक्तियों के साथ टेम्प्लेट Versions टैब, जिसमें उनकी निर्माण और प्रकाशन तिथियाँ दिखाई गई हैं

संस्करण दो और क्रियाओं का समर्थन करते हैं। ड्राफ़्ट के बदलाव त्यागें ताकि ड्राफ़्ट को वर्तमान में प्रकाशित संस्करण पर वापस रीसेट किया जा सके। या रोल बैक करें ताकि कोई पहले का प्रकाशित संस्करण फिर से send के लिए सक्रिय हो जाए। आप केवल किसी प्रकाशित संस्करण पर रोल बैक कर सकते हैं, कभी ड्राफ़्ट पर नहीं। रोल बैक करने से ड्राफ़्ट उस संस्करण की सामग्री से बदल जाता है, इसलिए ड्राफ़्ट में कुछ भी बिना सेव किया हुआ खो जाता है, और आगे का संपादन उस संस्करण से शुरू होता है जिस पर आपने रोल बैक किया। रोलबैक कोई नया संस्करण नहीं बनाता।

मौजूदा इमेज चुनने के लिए, आपको वर्कस्पेस की मीडिया लाइब्रेरी में पढ़ने की अनुमति चाहिए। नई इमेज अपलोड, पेस्ट या ड्रैग करके छोड़ने के लिए, आपको लिखने की अनुमति चाहिए। अगर इमेज डालें बंद है या आप लाइब्रेरी में खोज नहीं सकते या इमेज अपलोड नहीं कर सकते, तो वर्कस्पेस के व्यवस्थापक से मीडिया लाइब्रेरी की संबंधित अनुमति माँगें। सिर्फ़ टेम्पलेट संपादित करने की अनुमति से मीडिया लाइब्रेरी का ऐक्सेस नहीं मिलता।

डैशबोर्ड में विज़ुअल > इमेज डालें चुनकर अपनी मीडिया लाइब्रेरी में खोजें या 5 MB तक की PNG, JPEG, GIF या WebP इमेज अपलोड करें। स्थिर WebP इमेज PNG या JPEG में बदल दी जाती हैं। इमेज चुनकर उसका इमेज विवरण, दिखने की चौड़ाई, अलाइनमेंट और लिंक सेट करें। इमेज कोई जानकारी न देती हो, तभी उसे सजावटी इमेज के रूप में चिह्नित करें; लिंक वाली इमेज का विवरण बताना चाहिए कि लिंक कहाँ ले जाता है। हर भाषा के इमेज विवरण और लेआउट अलग रहते हैं।

चुनी हुई इमेज का विवरण, लिंक, चौड़ाई और अलाइनमेंट बनाए रखते हुए उसे बदलने के लिए इमेज बदलें का इस्तेमाल करें। आप विज़ुअल एडिटर में एक बार में एक इमेज फ़ाइल पेस्ट या ड्रॉप भी कर सकते हैं। सेव करने या टेस्ट भेजने से पहले अपलोड पूरा होने दें या उसे रद्द करें। प्रीव्यू जाँचें, फिर अन्य कार्रवाइयाँ > टेस्ट ईमेल खोलकर मौजूदा सामग्री खुद को भेजें। HTML में बदलाव करने के लिए कोड विकल्प भी उपलब्ध रहता है।

मीडिया लाइब्रेरी से इमेज हटाने पर वह पहले भेजे गए ईमेल से नहीं हटती। इमेज बदलने पर नया URL इस्तेमाल होता है, इसलिए पुराने संदेशों में मूल इमेज दिखती रहती है।

सेव करना एक रिवीज़न नंबर से सुरक्षित है। जिस भाषा को सेव कर रहे हैं उसके लिए आपने आखिरी बार जो revision पढ़ा था वह भेजें। अगर इस बीच किसी और ने वह भाषा बदल दी, तो उनके काम को ओवरराइट करने की बजाय सेव को conflict के रूप में अस्वीकार कर दिया जाता है। बिना शर्त सेव करने के लिए revision छोड़ दें। प्रकाशन और रोल बैक भी ड्राफ़्ट के अपने revision का उसी तरह उपयोग करते हैं।

एक से अधिक भाषाओं में सामग्री

एक टेम्प्लेट 25 भाषाओं तक की सामग्री रख सकता है, हर एक का अपना सब्जेक्ट और बॉडी, BCP-47 कोड जैसे en या pt-BR से टैग किया हुआ। एक भाषा टेम्प्लेट की डिफ़ॉल्ट होती है। टेम्प्लेट प्रकाशित करने से उसमें मौजूद हर भाषा एक साथ प्रकाशित होती है। आप अकेली एक भाषा प्रकाशित नहीं कर सकते, इसलिए सभी को पहले पूरा करना होगा। हर भाषा को एक सब्जेक्ट और बॉडी चाहिए, और टेम्प्लेट की डिफ़ॉल्ट भाषा उन भाषाओं में से एक होनी चाहिए जो आपने भरी हैं। अगर इनमें से कुछ भी छूटा है, तो कुछ भी प्रकाशित नहीं होता, और त्रुटि बताती है कि हर भाषा में क्या छूटा है ताकि आप एक ही बार में सब ठीक कर सकें। आपको हर भाषा पहले से पूरी करने की ज़रूरत नहीं: जो तैयार हैं उन्हें प्रकाशित करें, और बाकी बाद में जोड़ें।

भाषा को एक HTML बॉडी चाहिए। आप इसकी text छोड़ सकते हैं: प्रकाशन तब HTML से स्वचालित रूप से एक प्लेन-टेक्स्ट विकल्प बना देता है, ताकि आपको दूसरा हिस्सा खुद लिखे बिना दोनों भाग मिल जाएँ।

हर भाषा में प्रीव्यू टेक्स्ट भी हो सकता है, जिसे कभी-कभी प्रीहेडर कहते हैं: वह लाइन जो इनबॉक्स अपनी संदेश सूची में सब्जेक्ट के बाद दिखाता है। यह वैकल्पिक है, अधिकतम 255 कैरेक्टर, और सब्जेक्ट जैसे ही {{ variable }} प्लेसहोल्डर लेता है। इसे छोड़ दें और इनबॉक्स बॉडी की शुरुआती लाइन पर फ़ॉलबैक करता है, जो शायद ही कभी वह लाइन हो जो आप चुनते। प्रकाशन ऐसी भाषा पर प्रीव्यू टेक्स्ट अस्वीकार करता है जिसकी बॉडी में कोई HTML भाग नहीं है, क्योंकि मेल क्लाइंट प्रीव्यू लाइन केवल छिपे HTML मार्कअप से पढ़ता है, और उसी कारण {{ bird.unsubscribe_url }} को भी अस्वीकार करता है जिस कारण सब्जेक्ट में यह नहीं हो सकता: दोनों ऐसी जगह नहीं हैं जहाँ कोई लिंक जा सके।

दो सेटिंग्स ऐसी send को कवर करती हैं जो ऐसी भाषा नाम नहीं करती जिसके लिए टेम्प्लेट में सामग्री है, और ये अलग-अलग गलतियों से बचाती हैं:

सेटिंग	यह क्या नियंत्रित करती है
on_missing_language	जब कोई send ऐसी भाषा माँगती है जो टेम्प्लेट में नहीं है तो क्या होता है। fallback, डिफ़ॉल्ट, निकटतम मिलान प्रदान करता है। यह पहले उसी भाषा का व्यापक रूप आज़माता है, ताकि एक संग्रहित pt pt-BR के अनुरोध को पूरा कर सके। फिर यह टेम्प्लेट की डिफ़ॉल्ट भाषा पर फ़ॉलबैक करता है। fail इसके बजाय send को अस्वीकार करता है, ऐसी सामग्री के लिए जहाँ गलत भाषा भेजना न भेजने से बदतर है।
language_source_required	क्या किसी send को भाषा का नाम देना ज़रूरी है। यह डिफ़ॉल्ट रूप से बंद रहता है, इसलिए बिना भाषा नाम दिए send को डिफ़ॉल्ट भाषा मिल जाती है। इसे चालू करें, और वह send अस्वीकार कर दिया जाता है। एक broadcast अपने पूरे audience के लिए एक भाषा का नाम देता है, इसलिए इस सेटिंग वाले टेम्पलेट को broadcast भेजने से पहले उस भाषा का चयन करना ज़रूरी है।

सेटिंग

यह क्या नियंत्रित करती है

on_missing_language

जब कोई send ऐसी भाषा माँगती है जो टेम्प्लेट में नहीं है तो क्या होता है। fallback, डिफ़ॉल्ट, निकटतम मिलान प्रदान करता है। यह पहले उसी भाषा का व्यापक रूप आज़माता है, ताकि एक संग्रहित pt pt-BR के अनुरोध को पूरा कर सके। फिर यह टेम्प्लेट की डिफ़ॉल्ट भाषा पर फ़ॉलबैक करता है। fail इसके बजाय send को अस्वीकार करता है, ऐसी सामग्री के लिए जहाँ गलत भाषा भेजना न भेजने से बदतर है।

language_source_required

क्या किसी send को भाषा का नाम देना ज़रूरी है। यह डिफ़ॉल्ट रूप से बंद रहता है, इसलिए बिना भाषा नाम दिए send को डिफ़ॉल्ट भाषा मिल जाती है। इसे चालू करें, और वह send अस्वीकार कर दिया जाता है। एक broadcast अपने पूरे audience के लिए एक भाषा का नाम देता है, इसलिए इस सेटिंग वाले टेम्पलेट को broadcast भेजने से पहले उस भाषा का चयन करना ज़रूरी है।

आप इन दोनों को स्वतंत्र रूप से सेट कर सकते हैं। अकेले, fail केवल तब लागू होता है जब कोई send ऐसी भाषा नाम करती है जो हमारे पास नहीं है, इसलिए बिना नाम वाली send फिर भी पास हो जाती है। जब आप चाहते हैं कि हर send जानबूझकर एक भाषा नाम करे, तो दोनों सेटिंग्स एक साथ चालू करें।

वेरिएबल से पर्सनलाइज़ करना

सब्जेक्ट, प्रीव्यू टेक्स्ट और बॉडी में {{ variable }} प्लेसहोल्डर लिखें। हम उन्हें स्वचालित रूप से पहचानते हैं, हर भाषा को मिलाकर, ताकि आपको उन्हें अलग से घोषित न करना पड़े। प्लेसहोल्डर प्रीफ़िक्स दो प्रकारों को अलग करता है। bird. से शुरू होने वाला पथ हमारे डेटा से पढ़ता है, या तो कॉन्टैक्ट रिकॉर्ड या अनसब्सक्राइब लिंक। बाकी सब एक पैरामीटर है जिसे आप भेजते समय मान देते हैं।

पैरामीटर का नाम एक अकेला शब्द होता है, जैसे {{ animal }}। डॉटेड नाम ऐसी संरचना तक पहुँचने की कोशिश करता है जो पैरामीटर के पास नहीं है, इसलिए ऐसा प्रकाशित करना अस्वीकार किया जाता है: मान को अपने पैरामीटर के रूप में लिखें, या bird.contact.<attribute> से कॉन्टैक्ट डेटा पढ़ें।

सिंगल send या बैच पर, पैरामीटर का मान send के template.parameters ऑब्जेक्ट से आता है, उसके नाम से keyed। मानों का एक सेट उस send के हर प्राप्तकर्ता को कवर करता है। bird वह एक नाम है जिसे आप वहाँ उपयोग नहीं कर सकते: template.parameters key जिसका नाम bird है, 422 के साथ अस्वीकार किया जाता है।

Broadcast के पास कोई parameters ऑब्जेक्ट नहीं होता, इसलिए इसकी सामग्री केवल bird. प्लेसहोल्डर उपयोग कर सकती है। bird.contact.<attribute> हर प्राप्तकर्ता की अपनी contact properties से भरा जाता है, जो सामग्री को प्रति प्राप्तकर्ता पर्सनलाइज़ करता है। हर contact property अपनी key से उपलब्ध है, और तीन बिल्ट-इन फ़ील्ड भी: first_name, last_name, और email।

कोड उदाहरण

Hi {{ bird.contact.first_name }},

टेम्प्लेट में हर पैरामीटर को भेजते समय एक मान चाहिए। अन्यथा, API एक 422 लौटाता है जो छूटे पैरामीटर का नाम बताती है। हर भाषा के पैरामीटर के लिए मान दें क्योंकि चयनित भाषा फ़ॉलबैक सेटिंग्स पर निर्भर हो सकती है। छूटी contact property खाली मान के रूप में रेंडर होती है, इसलिए ग्राहक-दृश्य सामग्री के लिए फ़ॉलबैक जोड़ें: {{ bird.contact.first_name | default: "there" }}।

ब्रॉडकास्ट इस बारे में सख्त है कि वह कौन-से नाम स्वीकार करता है, क्योंकि प्लेसहोल्डर भरने के लिए उसके पास केवल contact properties हैं। इसके bird.contact.* प्लेसहोल्डर केवल किसी built-in फ़ील्ड या वर्कस्पेस में रजिस्टर की गई contact property का नाम ले सकते हैं। कोई भी अन्य प्लेसहोल्डर, जिसमें पैरामीटर भी शामिल है, ऐसा है जिसे ब्रॉडकास्ट भर नहीं सकता। भेजना अस्वीकार कर दिया जाता है, और त्रुटि उस प्लेसहोल्डर का नाम बताती है।

किसी property को आर्काइव करने से टेम्प्लेट के लिए केवल नई सामग्री बदलती है: property एडिटर के पिकर से हट जाती है, और ऐसे वर्शन को प्रकाशित करना जिसकी सामग्री उसे पढ़ती है, property का नाम बताते हुए अस्वीकार कर दिया जाता है। आर्काइव से पहले प्रकाशित वर्शन अप्रभावित रहते हैं।

प्लेसहोल्डर Liquid का उपयोग करते हैं, इसलिए फ़िल्टर और कंट्रोल फ़्लो सामान्य substitution के साथ काम करते हैं। {% if %} conditional और किसी array value पर {% for %} लूप दोनों ठीक हैं। कुछ constructs प्रकाशित करते समय अस्वीकार कर दिए जाते हैं, और त्रुटि ठीक-ठीक बताती है कि क्या बदलना है:

Partial includes, {% include %} या {% render %} का उपयोग करके।
increment, decrement, और ifchanged टैग।
money, format_date, format_time, json, inspect, और type फ़िल्टर।
empty या blank से तुलना करना। इसके बजाय .size == 0 का उपयोग करें।
वास्तविक ईमेल मार्कअप की ज़रूरत से कहीं अधिक गहराई तक नेस्टेड ब्लॉक।

ब्रॉडकास्ट का टेम्प्लेट {% for %} लूप बिल्कुल भी उपयोग नहीं कर सकता, क्योंकि ब्रॉडकास्ट प्रत्येक contact property के लिए एक ही मान भरता है और उसके पास iterate करने के लिए कुछ नहीं होता। अगर आपकी सामग्री को लूप चाहिए, तो इसे messages API के ज़रिए भेजें।

हर टेम्प्लेट Liquid का उपयोग करता है, वह भी जिसमें केवल {{ variable }} प्लेसहोल्डर हों। प्रकाशित करने से पहले, हम subject, preview text, HTML, और plain-text सामग्री को Liquid के रूप में validate करते हैं। हम प्रत्येक HTML आउटपुट में escape फ़िल्टर भी जोड़ते हैं जो पहले से escape या escape_once पर समाप्त नहीं होता, ताकि & या < वाला कोई मान आसपास के मार्कअप को बदल न सके। आरक्षित unsubscribe आउटपुट अपरिवर्तित रहता है ताकि भेजते समय उसे बदला जा सके। Subject line और plain-text body जैसी लिखी गई हैं वैसी ही रहती हैं। चूँकि प्रकाशित करते समय ये फ़िल्टर जोड़े जाते हैं, प्रकाशित वर्शन से पढ़ा गया HTML आपके सबमिट किए गए HTML से byte-identical नहीं भी हो सकता है।

पूरा URL सीधे href में रखें, जैसे <a href="{{ sign_in_url }}">Sign in</a>। पूरे मान पर url_encode न लगाएँ। यह https://, /, ?, और & को percent-encode कर देता है, जिससे परिणाम absolute link के रूप में काम नहीं करता। हम URL संरचना को बनाए रखते हुए HTML escaping जोड़ते हैं। जब कोई पैरामीटर एक URL component देता है, तो उस component को स्पष्ट रूप से encode करें: <a href="https://example.com/search?q={{ query | url_encode }}">Search</a>।

प्रकाशित करने से पहले प्रीव्यू

सैंपल मानों के साथ टेम्प्लेट रेंडर करें और subject line तथा HTML और plain-text body वापस पाएँ जो एक send डिलीवर करता। प्रीव्यू हमारे लोकल Liquid रेंडरर का उपयोग करता है और डिफ़ॉल्ट रूप से ड्राफ़्ट रेंडर करता है, इसी तरह आप लाइव होने से पहले बदलाव जाँचते हैं। यह इसके बजाय प्रकाशित वर्शन भी रेंडर कर सकता है। यह आपके अपने टेम्प्लेट और हमारे built-in टेम्प्लेट दोनों के लिए काम करता है, और कुछ भी भेजा नहीं जाता।

आप ड्राफ़्ट पढ़वाने के बजाय सामग्री स्वयं भी दे सकते हैं। Subject और body पास करें और वे रेंडर हो जाएँगी, ठीक वैसे ही जैसे ड्राफ़्ट को माना जाता है, यही वह तरीका है जिससे एडिटर बिना कुछ सहेजे टाइप करते समय बदलाव दिखा सकता है।

पर्सनलाइज़ेशन आपके लिए भर दिया जाता है, इसलिए जो वापस आता है वह {{ }} प्लेसहोल्डर की बजाय तैयार कॉपी की तरह पढ़ा जाता है। एक contact नाम दें और हर bird.contact.<attribute> उस contact की अपनी properties के विरुद्ध resolve होता है, इसी तरह आप किसी को भेजने से पहले अपने शब्दों को एक वास्तविक रिकॉर्ड के साथ जाँचते हैं। ये मान उसी projection से आते हैं जिसका उपयोग ब्रॉडकास्ट अपने प्लेसहोल्डर भरने के लिए करता है, इसलिए प्रीव्यू वही उत्तर देता है जो send देता।

contact छोड़ दें और इसके बजाय stand-in मान भरे जाते हैं: पहले और अंतिम नाम के लिए Bird और Test, ईमेल के लिए bird.test@example.com, और प्रत्येक अन्य property का अपना रजिस्टर किया हुआ फ़ॉलबैक। बिना फ़ॉलबैक वाली किसी संदर्भित property को ब्रैकेट में उसकी key के रूप में रेंडर किया जाता है, जैसे [loyalty_tier], जो आपको यह दोनों बातें बताता है कि मान एक प्लेसहोल्डर है और किस property को अभी भी फ़ॉलबैक चाहिए।

Contact को उसकी वर्तमान स्थिति के अनुसार पढ़ा जाता है। इससे प्रीव्यू उस सामग्री की जाँच के लिए सही टूल बनता है जो आप भेजने वाले हैं, और यह पूछने के लिए गलत टूल है कि पहले के किसी send में क्या था। किसी send ने वास्तव में क्या डिलीवर किया यह पढ़ने के लिए, उस संदेश को ईमेल लॉग में खोलें, जो उसे उन मानों से रेंडर करता है जो उस send में थे।

एक विशिष्ट भाषा रेंडर करने के लिए language जोड़ें, या टेम्प्लेट की डिफ़ॉल्ट भाषा के लिए इसे छोड़ दें। प्रतिक्रिया बताती है कि कौन-सी भाषा रेंडर हुई, जो तब मायने रखता है जब आपने जो माँगी वह उपलब्ध नहीं है और टेम्प्लेट की on_missing_language ने निकटतम मिलान दिया।

अगर ड्राफ़्ट में ऐसा पर्सनलाइज़ेशन है जो प्रकाशित करते समय अस्वीकार हो जाता, तो प्रीव्यू वही त्रुटि लौटाता है, इसलिए यह समस्याएँ जल्दी खोजने का भी काम करता है।

डैशबोर्ड के टेम्प्लेट बिल्डर में, बाएँ रेल के निचले भाग में Preview with contact data आप जो भी एडिट कर रहे हैं उसके बगल में रेंडर किया हुआ ईमेल दिखाता है, विज़ुअल और कोड एडिटर दोनों में। इसके नीचे का पिकर चुनता है कि किसका डेटा प्लेसहोल्डर भरता है, और Sample data ऊपर बताए गए stand-in मान हैं।

टेम्प्लेट के साथ भेजना

Send के template फ़ील्ड को एक ऐसे ऑब्जेक्ट पर सेट करें जो टेम्प्लेट का नाम देता हो, या तो id (emt_...) द्वारा या slug द्वारा, दोनों में से ठीक एक का उपयोग करें। इसके variable मान template.parameters में रखें। कोई विशिष्ट भाषा चुनने के लिए language जोड़ें, या टेम्प्लेट की डिफ़ॉल्ट भाषा भेजने के लिए इसे छोड़ दें, जब तक कि टेम्प्लेट हर send से एक भाषा नाम देने की ज़रूरत न रखता हो। subject, html, और text को पूरी तरह छोड़ दें, क्योंकि टेम्प्लेट उन्हें पहले से प्रदान करता है।

कोड उदाहरण

{
  "from": "hello@yourdomain.com",
  "to": ["delivered@messagebird.dev"],
  "category": "transactional",
  "template": {
    "slug": "welcome-email",
    "parameters": { "first_name": "Jane" }
  }
}

एक व्यवहार जिसकी योजना बनानी चाहिए: टेम्प्लेट की category एक डिफ़ॉल्ट है, और send का अपना category उसे ओवरराइड करता है। category हटा दें, और send टेम्प्लेट की category इनहेरिट करता है, इसलिए एक operational टेम्प्लेट हर कॉल पर दोहराए बिना transactional के रूप में भेजता है। category सेट करें, और आपका मान जीतता है। बाकी send-side contract टेम्प्लेट के साथ भेजना में है।

डैशबोर्ड के बाहर ऑथरिंग

पूरा lifecycle डैशबोर्ड के बाहर उपलब्ध है। प्रकाशन चरण को वहाँ submit कहा जाता है, और यही वह ऑपरेशन है जो ड्राफ़्ट को अगले प्रकाशित वर्शन में बदलता है:

कोड उदाहरण

bird email templates create welcome-email --category marketing --source html
bird email templates versions languages set <emt_...> <emv_...> en --subject "Hi {{ bird.contact.first_name }}" --html "<p>Hello</p>"
bird email templates versions submit <emt_...> <emv_...> --validate-only   # report problems, freeze nothing
bird email templates versions submit <emt_...> <emv_...>                   # freeze, go live

create टेम्प्लेट को उसकी draft_version_id के साथ लौटाता है, जिसे हर version और language कमांड लेता है। --validate-only वास्तविक submit जैसी ही completeness जाँच चलाता है, बिना कुछ फ़्रीज़ किए, इसलिए यह एक ही बार में हर भाषा की हर समस्या खोजने का सस्ता तरीका है। टेम्प्लेट को वापस पढ़ने से आपको उसका metadata और प्रति-भाषा स्थिति मिलती है, लेकिन सामग्री नहीं। सामग्री एक version की languages पर होती है, एक बार में एक भाषा।

SDKs email.templates के अंतर्गत typed methods के रूप में वही lifecycle रखते हैं, जिसमें version और language ऑपरेशन email.templates.versions और email.templates.versions.languages के रूप में नेस्टेड हैं। एक agent email_templates_* MCP tools के ज़रिए उन्हीं ऑपरेशन तक पहुँचता है।

अगले कदम

ईमेल भेजना: पूरा send पेलोड, और टेम्प्लेट वाले sends इसमें कैसे फिट होते हैं
Categories: प्रत्येक send पर marketing बनाम transactional चुनना
bird email templates: टर्मिनल से टेम्प्लेट प्रबंधित करना
API reference: सभी अठारह टेम्प्लेट ऑपरेशन के लिए पूर्ण request और response schemas
SDKs: TypeScript, Python, PHP और Go में typed email.templates methods
MCP server: एक agent को टेम्प्लेट ऑथर और प्रकाशित करने देना
ईमेल टेम्पलेट कैसे बनाएँ: एक वीडियो जो डैशबोर्ड में एक टेम्प्लेट बनाता है और फिर एक agent से दूसरा बनवाता है

संबंधित संसाधन