दस्तावेज़ पर जाएँ
API

टेम्पलेट सूचीबद्ध करें

connection के सारे टेम्पलेट, नवीनतम पहले, keyset पेजिनेशन के साथ।

GETapi.openemail.uk/templates

असली कॉल आपकी अपनी कुंजी से आपके वर्कस्पेस पर चलाता है।

GET /templates

connection के सारे टेम्पलेट, नवीनतम पहले, keyset पेजिनेशन के साथ।

दो engines

shell
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"

टेम्पलेट एक बार संग्रहीत और कई बार भेजी गई body है, और वह उसे लिखने वाले का नहीं बल्कि connection का होता है। वर्कस्पेस key वही टेम्पलेट देखती है जो सहकर्मी देखता है, और लेखक का अकाउंट हटाने पर वे उसके साथ नहीं जाते।

engine: "blocks" एक ट्री संग्रहीत करता है जिसके नोड प्रकार @react-email/components के exports हैं (Section, Row, Column, Container, Text, Heading, Button, Link, Img, Hr, Markdown, CodeBlock और CodeInline) और जिसके props उन्हीं कंपोनेंट के अपने हैं। इसे भीतर आते समय मान्य किया जाता है, इसलिए ख़राब नोड बाद में टूटा हुआ ईमेल नहीं, बल्कि उसे लिखने वाली कॉल पर 422 होता है।

engine: "html" वह मार्कअप संग्रहीत करता है जो आपके पास पहले से है, और संस्करण प्रकाशित होते समय उसे एक बार sanitise किया जाता है। जब आपके टेम्पलेट आपकी अपनी रिपॉज़िटरी में रहने वाले react-email कंपोनेंट हों, तो यही चुनना चाहिए: अपने बिल्ड में @react-email/render से कंपोनेंट रेंडर करें और नतीजा पोस्ट करें। कोई JSX एंडपॉइंट नहीं है और न होगा। API HTML लेता है क्योंकि मेल क्लाइंट HTML ही पढ़ता है, और कॉलर का कंपोनेंट चलाने से ऐसा sandbox मोल लेना पड़ता जिसकी किसी को ज़रूरत नहीं।

किस रूप में घोषितकौन भरता हैभेजते समय ग़ायब हो तो
`slots`जो भी टेम्पलेट संपादित करता हैslot का अपना default रेंडर होता है
`props`जो भी भेजता हैmissing_template_prop, एक 422, और कोई मेल बाहर नहीं जाती

दोनों body में और subject में {{key}} के रूप में लिखे जाते हैं, और दोनों एक kind (text, url या image) रखते हैं जो तय करता है कि प्रतिस्थापन के समय मान को कैसे escape किया जाए। जिस key को कुछ भी घोषित नहीं करता, वह प्रकाशन पर फेल होती है; जिस url मान की स्कीम http, https या mailto नहीं है, उसे रेंडर करने के बजाय अस्वीकार कर दिया जाता है।

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

उदाहरण

templates:read चाहिए। limit 100 तक जाता है, status इसे draft, active या archived तक सँकरा करता है, और cursor अपारदर्शी है, इसलिए ख़ुद बनाने के बजाय वही nextCursor वापस भेजें जो आपको दिया गया था।

curl
curl "$OE/templates?limit=25&status=active" -H "$AUTH"
प्रतिक्रिया
{  "object": "list",  "data": [    {      "object": "template",      "id": "tpl_9c1f0a4b7e05d3862c1f0a44",      "name": "Order shipped",      "slug": "order-shipped",      "description": null,      "status": "active",      "publishedVersion": 3,      "latestVersion": 4,      "createdAt": "2026-08-01T09:12:44.000Z",      "updatedAt": "2026-08-28T16:03:10.000Z"    }  ],  "hasMore": false,  "nextCursor": null}

publishedVersion वह है जो बिना version वाला send हल करता है और latestVersion उसके ऊपर बैठा ड्राफ़्ट है। दोनों का अलग होना मतलब किसी ने संपादित किया और प्रकाशित नहीं किया। यह त्रुटि नहीं है, और डिप्लॉय लॉग में इसे दिखाना सार्थक है।

एक पंक्ति मेटाडेटा है। घोषित slots और props retrieval से लौटते हैं, और जब आपको जानना हो कि किसी को क्या भेजना है तो यही कॉल करनी है।