معظم أدوات إرسال البريد المعاملاتي لا تعرض إلا HTML عاديًا. أما POST /api/v1/send في وضع القالب فيعرض أحد مشاريعك في الاستوديو، بما في ذلك محرك البدائل الكامل والعناصر التفاعلية. فيمكن لإيصال أو رسالة تأكيد يطلقها خادمك الخلفي أن تحمل عنصر تقييم أو عرض بيع إضافي في عنصر منتج تمامًا كما يفعل الإرسال التسويقي.
الإيصال من أعلى رسائل الشركة معدلًا للفتح — وهو دائمًا تقريبًا أبسطها شكلًا، لأنه يُولَّد عادةً بأي مكتبة معاملاتية كانت الأسهل في التوصيل، لا بأي شيء مرتبط بنظام تصميم.
صمّمه مرة واحدة، وأطلقه من خادمك الخلفي
ابنِ الإيصال أو رسالة التأكيد كمشروع عادي في الاستوديو، مع أي عناصر مناسبة — تقييم لقياس CSAT بعد الشراء، أو عرض بيع إضافي لمنتج ذي صلة في عنصر منتج. ثم يستدعي خادمك الخلفي Send API في وضع القالب مع معرّف المشروع وكائن mergeData بديلًا عن القيم الديناميكية لذلك الطلب تحديدًا.
صنّفه معاملاتيًا، بالشكل الصحيح
ضبط type على "transactional" يتجاوز حظر الإرسال الناتج عن إلغاء الاشتراك — فالإيصال يجب أن يصل حتى إلى من ألغى اشتراكه في الرسائل التسويقية — لكنه لا يتجاوز أبدًا حظر الإرسال الناتج عن الارتداد، لأن العنوان السيئ فعلًا لا ينبغي الاستمرار في الإرسال إليه أيًّا كان نوع البريد.
مصادَق عليه مثل أي تكامل API
مفتاح API مُسمًّى لكل مالك، بمصادقة Bearer، يُنشأ ويُلغى من قسم المطوّرين في لوحة التحكم. وتمنع ترويسة Idempotency-Key الطلبَ المُعاد من إرسال الإيصال مرتين.
ما الذي لا ينتقل
يتخطى الوضع الحرّ (دون projectId، فقط html/text خام) مسار العرض بالكامل — لا وسوم دمج، ولا محرك بدائل، ويُرسَل تمامًا كما هو. وهذا هو الخيار الصحيح لشيء مثل رمز OTP لمرة واحدة؛ أما وضع القالب فهو ما يستحق الاستخدام حين يستفيد البريد نفسه من عنصر تفاعلي.
البدء
ابنِ القالب المعاملاتي كمشروع في الاستوديو بالعناصر التفاعلية التي تريدها، وأنشئ مفتاح API من قسم المطوّرين، واستدعِ POST /api/v1/send في وضع القالب مع mergeData وtype: "transactional".