Python
शेड्यूल और रद्द करना
`scheduledAt`, `emails.reschedule` और `emails.cancel`।
बाद में भेजना
from datetime import datetime, timezone from openemail import openemailfrom openemail.types import EmailSend message: EmailSend = {'from': sender, 'to': recipient, 'subject': subject, 'text': text} openemail.emails.send({**message, 'scheduledAt': 'PT1H'})openemail.emails.send({**message, 'scheduledAt': datetime(2027, 1, 1, 9, 0, tzinfo=timezone.utc)})openemail.emails.send({**message, 'scheduledAt': '2027-01-01T09:00:00.000Z'})एक datetime, एक ISO-8601 क्षण, या PT1H / P2D जैसी कोई अवधि। एक साल तक आगे, अतीत में कभी नहीं।
datetime UTC में भेजा जाता है, और naive वाले को पहले इस मशीन का स्थानीय समय माना जाता है, उसी तरह जैसे astimezone उसे पढ़ता है, इसलिए जब समय क्षेत्र मायने रखता हो तो aware वाला पास करें। timedelta स्वीकार नहीं किया जाता: उसे datetime.now(timezone.utc) में जोड़ें, या PT1H जैसी कोई अवधि भेजें।
खिसकाना और रोकना
from datetime import datetime, timedelta, timezone from openemail import openemailfrom openemail.types import EmailSend message: EmailSend = {'from': sender, 'to': recipient, 'subject': subject, 'text': text} queued = openemail.emails.send({**message, 'scheduledAt': 'PT1H'}) openemail.emails.reschedule(queued['id'], datetime.now(timezone.utc) + timedelta(days=1))openemail.emails.cancel(queued['id'])केवल queued और scheduled संदेश रोके जा सकते हैं; इससे आगे बढ़ चुका कुछ भी conflict_error है, क्योंकि उसका कुछ हिस्सा पहले ही किसी के मेलबॉक्स में है। पहले से रद्द हो चुके संदेश को रद्द करना सफल होता है और कुछ नहीं बदलता।
इसके बजाय एक undo खिड़की
from openemail import openemailfrom openemail.types import EmailSend message: EmailSend = {'from': sender, 'to': recipient, 'subject': subject, 'text': text} openemail.emails.send({**message, 'cancellableForSeconds': 30})निर्धारित संदेश तो जाने तक वैसे भी रद्द किया जा सकता है, इसलिए दोनों को मिलाया नहीं जा सकता और सर्वर इसे अस्वीकार करता है। तत्काल संदेश पर undo-send खिड़की के लिए इसी का उपयोग करें।
पैरामीटर: निर्धारण
scheduledAtdatetime | str- `emails.send` पर कब भेजना है: एक `datetime`, एक ISO-8601 क्षण, या `PT1H` या `P2D` जैसी कोई अवधि, जिसे क्लाइंट तार के लिए स्ट्रिंग में बदल देता है। कम से कम एक सेकंड भविष्य में और अधिकतम 365 दिन आगे; दोनों में से कोई भी सीमा टूटने पर `scheduledAt` पर `validation_error`। सामान्य भाषा स्वीकार नहीं होती, क्योंकि "next Tuesday" का ग़लत विश्लेषण संदेश को ऐसे समय भेज देता है जिसे वापस नहीं लिया जा सकता।
cancellableForSecondsint- तत्काल send पर undo-send खिड़की: 0 से 900 के बीच एक integer, डिफ़ॉल्ट 0। 0 से ऊपर का कोई भी मान `scheduledAt` के साथ अस्वीकार होता है, जो जाने तक वैसे भी रद्द किया जा सकता है; और इस तरह रोका गया संदेश `scheduled` नहीं बल्कि `queued` पर बैठता है। यह वही टालने की व्यवस्था है, बस छोटी देरी के साथ।
idstrआवश्यक- `msg_…` id, और `emails.cancel` तथा `emails.reschedule` दोनों का पहला आर्ग्युमेंट। दोनों को अपने अलग scope की नहीं बल्कि `emails:send` की ज़रूरत होती है, और दोनों कुंजी के अपने workspace के भीतर ही हल होते हैं, इसलिए किसी दूसरे workspace की id ठीक वैसे ही `not_found_error` है जैसे कोई ऐसी id जो कभी थी ही नहीं।
scheduled_atdatetime | strआवश्यक- नया समय, `emails.reschedule` के दूसरे आर्ग्युमेंट के रूप में, उन्हीं नियमों से और उसी एक-साल की खिड़की के ख़िलाफ़ विश्लेषित, और अंतर्निहित `PATCH /emails/{id}` यही एकमात्र चीज़ बदलेगा। अवधि उस समय के सापेक्ष होती है जब सर्वर उसे पढ़ता है, इसलिए दोबारा किया गया reschedule पहली बार के मुक़ाबले थोड़ा बाद में उतरता है: बाद में, पहले कभी नहीं।
प्रतिक्रिया: EmailResource
objectLiteral['email']- हमेशा `email`। दोनों कॉल किसी पावती के बजाय पूरा संदेश लौटाती हैं, इसलिए जो बदला उसे देखने के लिए कुछ भी दोबारा लाना नहीं पड़ता; `emails.send` यही आकार लौटाता है, साथ में `replayed`।
idstr- `msg_…` handle। संदेश के पूरे जीवन के लिए स्थिर, और उस पर होने वाली हर दूसरी कॉल यही id लेती है।
statusEmailStatus- cancel के बाद `cancelled` और reschedule के बाद `scheduled`, उस संदेश के लिए भी जो undo खिड़की के पीछे केवल `queued` था और जिसे reschedule असली निर्धारण में बदल देता है। केवल `queued` और `scheduled` संदेश खिसकाए या रोके जा सकते हैं; इससे आगे बढ़ चुका कुछ भी `email_not_cancellable` कोड के साथ `conflict_error` है, क्योंकि उसका कुछ हिस्सा पहले ही किसी के मेलबॉक्स में है।
scheduledAtstr | None- वह ISO क्षण जब संदेश dispatch होना है। यह undo खिड़की के लिए भी सेट होता है और `scheduledAt` वाले send के लिए भी, क्योंकि दोनों एक ही व्यवस्था हैं; और सादे तत्काल send पर null।
cancellableUntilstr | None- रद्द करना कब काम करना बंद कर देता है, जो दोनों टाले गए रास्तों पर `scheduledAt` जैसा ही क्षण है। तत्काल send पर null, जो कॉल लौटने तक जा चुका होता है।
sentAtstr | None- संदेश वास्तव में कब रवाना हुआ। प्रतीक्षा के दौरान null, और रद्द हुए संदेश पर हमेशा के लिए null।
messageIdstr | None- RFC 5322 Message-ID, MIME बनने तक null, इसलिए इन दोनों कॉलों की पहुँच वाले संदेश पर हमेशा null। यह न तो API को संबोधित करने की चीज़ है और न वह जिस पर बाद का कोई bounce लौटता है: sending सेवा बाहर जाते समय इस header को दोबारा लिख देती है।
threadIdstr | None- वह thread जिसका यह संदेश हिस्सा है, जो रिक्वेस्ट से लिया जाता है और भेजे जाने के बाद transport जो बताए उससे दोबारा लिखा जाता है। जब यह उत्तर न हो तब null।
transportEmailTransport | str | None- bytes कैसे रवाना हुए; dispatch तक null, इसलिए हर उस संदेश पर null जिसे cancel या reschedule लौटा सकता है। test-mode send `test` दर्ज करता है, और union खुला रहता है ताकि कोई ऐसा transport जिसका नाम यह SDK अभी नहीं लेता, breaking change न बने।
attemptsint- dispatch ने इस पंक्ति पर कितनी बार दावा किया। यह सफल send से नहीं बल्कि दावे से बढ़ता है, और अब भी प्रतीक्षा कर रहे किसी भी संदेश के लिए 0 होता है।
lastErrorstr | None- संदेश के ख़िलाफ़ दर्ज आख़िरी विफलता; जब तक कुछ विफल न हुआ हो तब तक null। जिस टाले गए send का job क़तार में नहीं डाला जा सका, वह यहाँ `Could not schedule: …` के रूप में लिखा जाता है और `failed` पर चला जाता है, और यही वह एक तरीक़ा है जिससे निर्धारित संदेश बिना किसी के कहे रद्द-योग्य नहीं रह जाता।
fromstr- वह पता जिसके रूप में संदेश को बाहर जाने की अनुमति मिली: भेजा गया `from`, सादा और छोटे अक्षरों में संग्रहित। प्रदर्शित नाम यहाँ गिरा दिया जाता है, क्योंकि `emails.list` का `from_` फ़िल्टर बराबरी पर तुलना करता है।