API البريد الإلكتروني: الدليل الشامل لإرسال البريد الإلكتروني برمجيًا (2026)

تتيح واجهة برمجة البريد الإلكتروني لتطبيقك إرسال البريد الإلكتروني عبر طلبات HTTP.

يبدو هذا بسيطًا، لكن هذا القرار يؤثر في موثوقية المنتج، والقدرة على التسليم، وسير عمل الهندسة، والتحليلات، والامتثال، وتجربة العميل، وعمليات الدعم.

كان للنسخة القديمة من هذه الصفحة مخطط جيد لكن دون عمق كافٍ. قارنت بين واجهات API، وعرضت مثالًا سريعًا على Brevo، وشرحت متى تُستخدم API مقابل SMTP. يحافظ هذا التحديث على تلك البنية، ويوسّعها لتصبح دليل تنفيذ كاملًا ومدعومًا بالبحث، باستخدام محتوى صفحات المزودين إلى جانب التوثيق الحالي وصفحات الأسعار لكل من Brevo وSendGrid وMailgun وAmazon SES وPostmark، وتوثيق Tajo الخاص بواجهة برمجة الرسائل.

الإجابة السريعة

استخدم API البريد الإلكتروني عندما تحتاج إلى بريد إلكتروني يُحفّزه التطبيق:

• التحقق من التسجيل.
• إعادة تعيين كلمة المرور.
• تسجيل الدخول برابط سحري (magic link).
• تأكيد الطلب.
• إشعار الشحن.
• الفاتورة أو الإيصال.
• دعوة للمنتج.
• تهيئة التجربة المجانية.
• تنبيه استخدام.
• إشعار فشل الدفع.
• تذكير بالتجديد.
• أتمتة دورة حياة مبنية على أحداث المنتج.

استخدم SMTP عندما لا يدعم نظام الإرسال سوى بيانات اعتماد SMTP، أو عندما تحتاج إلى طبقة نقل بريد موحّدة لتطبيق قديم، أو إضافة، أو خادم، أو أداة داخلية.

يعتمد أفضل اختيار لـAPI البريد الإلكتروني على المجموعة التقنية:

لا تختر بناءً على السعر المُعلن فقط. تشمل تكلفة API البريد الإلكتروني أيضًا وقت الهندسة، والعمل على القدرة على التسليم، ونمذجة البيانات، والمراقبة، والدعم، ومخاطر الترحيل المستقبلي.

API البريد الإلكتروني مقابل SMTP

يمكن لكل من API وSMTP إرسال البريد الإلكتروني. يكمن الفرق في كيفية تسليم تطبيقك الرسالة إلى منصة الإرسال.

يُعد SMTP بروتوكول نقل البريد العريق. يعمل مع أدوات كثيرة، ولا يزال مفيدًا عندما يتوقع المنتج إعدادات المضيف والمنفذ واسم المستخدم وكلمة المرور.

API البريد الإلكتروني هو واجهة HTTP. يرسل تطبيقك طلبًا إلى نقطة نهاية (endpoint) تتضمن المصادقة، والمستلمين، والمحتوى، وبيانات القالب، والبيانات الوصفية، وأحيانًا تفاصيل الجدولة أو الإرسال بالدفعات.

القاعدة العملية: إذا كنت تملك كود التطبيق، ابدأ بـAPI. إذا كنت تُعدّ أداة من طرف ثالث لا تدعم سوى SMTP، استخدم SMTP.

كيف تعمل API البريد الإلكتروني

يتكوّن مسار إرسال أساسي من سبع خطوات:

1. ينشئ تطبيقك حدثًا، مثل user_signed_up أو order_paid.
2. يختار التطبيق نوع الرسالة.
3. يحمّل التطبيق بيانات المستلم والمرسل والقالب والتخصيص.
4. يرسل التطبيق طلب HTTP مصادَق عليه إلى مزود البريد الإلكتروني.
5. يتحقق المزود من الطلب ويضع الرسالة في قائمة الانتظار.
6. يُعيد المزود استجابة تتضمن النجاح أو الخطأ أو معرّفات الرسالة.
7. تُبلّغ Webhooks نظامك بأحداث التسليم أو الارتداد أو النقر أو الشكوى أو إلغاء الاشتراك.

طلب API ليس سوى جزء واحد. يحتاج التنفيذ الموثوق أيضًا إلى التماثل التكراري (idempotency)، وإعادة المحاولات، والتسجيل، والتعامل مع الإيقاف، والتنبيهات، وحوكمة البيانات.

بداية سريعة: إرسال بريد إلكتروني عبر API الخاصة بـ Brevo

تستخدم API البريد التشغيلي من Brevo طلبًا مصادَقًا عليه إلى نقطة النهاية /v3/smtp/email. يمكن أن تتغيّر أسماء حزمة SDK والحقول بدقة، لذا استخدم مرجع API الخاص بالمزود كمصدر موثوق عند التنفيذ.

مثال على الطلب:

curl --request POST \
  --url https://api.brevo.com/v3/smtp/email \
  --header 'api-key: YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --data '{
    "sender": {
      "name": "Your App",
      "email": "[email protected]"
    },
    "to": [
      {
        "email": "[email protected]",
        "name": "Customer"
      }
    ],
    "subject": "Welcome to your account",
    "htmlContent": "<h1>Welcome</h1><p>Your account is ready.</p>"
  }'

لا ينبغي أن يُدرج كود الإنتاج مفاتيح API مباشرةً في الكود. خزّن الأسرار في مدير أسرار أو متغير بيئة، وقم بتدويرها، وقيّد الوصول إليها، ولا تعرضها أبدًا في كود الواجهة الأمامية.

بنية API البريد الإلكتروني في الإنتاج

لا ينبغي أن يُرسل تكامل API البريد الإلكتروني في الإنتاج مباشرةً من كل مُتحكّم (controller) أو معالج مسار.

استخدم طبقة رسائل صغيرة:

1. يحدث حدث في المنتج.
2. يكتب التطبيق الحدث إلى قائمة انتظار، أو مهمة، أو ناقل أحداث.
3. تربط خدمة البريد الإلكتروني الحدث بقالب.
4. تتحقق خدمة البريد الإلكتروني من موافقة المستلم وقواعد الإيقاف.
5. تستدعي خدمة البريد الإلكتروني API الخاص بالمزود.
6. تسجّل خدمة البريد الإلكتروني معرّف الرسالة الخاص بالمزود.
7. تُحدّث Webhooks حالة الرسالة لاحقًا.

هذا يبقي كود المنتج نظيفًا، ويجعل عزل إخفاقات البريد الإلكتروني أسهل.

الحقول الداخلية الموصى بها:

• event_id.
• message_type.
• recipient_id.
• recipient_email.
• template_id.
• locale.
• provider.
• provider_message_id.
• idempotency_key.
• status.
• error_code.
• created_at.
• sent_at.
• delivered_at.

استخدم مفاتيح التماثل التكراري (idempotency keys) للرسائل الحرجة. يجب ألا تؤدي إعادة محاولة إلى إرسال ثلاث رسائل لإعادة تعيين كلمة المرور بسبب انتهاء مهلة طلب شبكة بعد أن قبِل المزود الرسالة الأولى.

مقارنة أفضل واجهات API للبريد الإلكتروني

Brevo

تُعد Brevo مفيدة عندما يكون البريد التشغيلي جزءًا من نظام تواصل أوسع مع العملاء.

اختر Brevo عندما:

• تحتاج إلى بريد تشغيلي بالإضافة إلى الحملات وCRM والأتمتة وSMS أو WhatsApp.
• يجب أن تُحفّز بيانات التجارة الإلكترونية رسائل دورة الحياة.
• تحتاج رسائل التسويق والمنتج إلى مشاركة ملفات جهات الاتصال.
• يحتاج غير المطورين إلى الوصول إلى القوالب والتقارير.
• تريد منصة واحدة بدلًا من أدوات منفصلة لكل قناة.

انتبه إلى:

• الفرق بين إعداد البريد التسويقي والبريد التشغيلي.
• ملكية القوالب بين الهندسة والتسويق.
• حدود المعدل وقيود الخطة.
• كيفية مزامنة بيانات جهات الاتصال.
• كيفية تطبيق قواعد إلغاء الاشتراك والإيقاف على فئات الرسائل المختلفة.

يغطي توثيق Brevo الإرسال التشغيلي، والإرسال بالدفعات، ووضع الاختبار (sandbox)، وترحيل SMTP، وWebhooks، وحزم SDK، وصفحات مرجع API. استخدم هذا التوثيق لتفاصيل التنفيذ.

SendGrid

تُعد SendGrid خيارًا شائعًا للفرق التي تريد API بريد إلكتروني ناضجًا موجّهًا للمطورين، بدعم واسع للغات والمنصات.

اختر SendGrid عندما:

• يريد المطورون API بريد إلكتروني مألوفًا ومنظومة SDK.
• تحتاج إلى بريد تشغيلي وتسويقي من المزود نفسه.
• لديك بنية تحتية قائمة من Twilio.
• تحتاج إلى webhooks للأحداث وضوابط إرسال مفصّلة.

انتبه إلى:

• ميزات القدرة على التسليم والدعم المضمّنة في الخطة المختارة.
• كيفية إدارة القوالب عبر البيئات.
• ما إذا كان ينبغي أن يتشارك البريد التسويقي والتشغيلي بنية الحساب نفسها.

Mailgun

بُنيت Mailgun حول الإرسال الذي يقوده المطورون وسير عمل يعتمد على API أولًا.

اختر Mailgun عندما:

• تمتلك الهندسة البنية التحتية للبريد الإلكتروني.
• تحتاج إلى إرسال عبر HTTP، ونسخ احتياطي عبر SMTP، وسجلات، ومسارات للبريد الوارد، وأدوات تحقق.
• تريد مزودًا واضحًا بشأن عمليات القدرة على التسليم.

انتبه إلى:

• ميزات التحقق والتحليلات والقدرة على التسليم المضمّنة.
• الاحتفاظ بالبيانات والوصول إلى السجلات.
• توقعات الدعم أثناء الترحيل والتسخين (warmup).

Amazon SES

تُعد Amazon SES موجّهة نحو البنية التحتية.

اختر Amazon SES عندما:

• يعمل تطبيقك بالفعل بشكل كبير على AWS.
• لديك موارد هندسية لتولّي جزء أكبر من الإعداد.
• تحتاج إلى إرسال بحجم كبير بنظام الدفع حسب الاستخدام.
• تريد تكاملًا وثيقًا مع IAM أو CloudWatch أو SNS أو Lambda أو خدمات AWS الأخرى.

انتبه إلى:

• إزالة وضع الاختبار والوصول إلى الإنتاج.
• إعداد هوية النطاق.
• التعامل مع الارتداد والشكاوى.
• قرارات عناوين IP المخصصة.
• المراقبة والتنبيهات.
• التكلفة الهندسية لبناء ميزات يدرجها مزودون آخرون في واجهة المنتج.

يمكن أن تكون SES ممتازة عند الحجم الكبير، لكنها ليست الخيار الأقل جهدًا لكل فريق.

Postmark

تركّز Postmark على البريد التشغيلي.

اختر Postmark عندما:

• تكون موثوقية البريد التشغيلي ووضوحه أهم من شمولية أداة تسويقية متكاملة.
• تريد تدفقات رسائل تفصل بين أنواع البريد الإلكتروني.
• تحتاج إلى قوالب، وبريد وارد، وأحداث تسليم في منتج مباشر.

انتبه إلى:

• فئات التسعير عند حجمك.
• المدة التي تحتاجها للاحتفاظ بالأحداث والرسائل.
• ما إذا كان يجب أن يكون التسويق الجماعي في تدفق أو منصة منفصلة.

Tajo

تُعد Tajo مناسبة عندما يكون إرسال البريد الإلكتروني مرتبطًا بالتجارة الإلكترونية، وأحداث العملاء، والأتمتة المتصلة بـBrevo.

استخدم Tajo عندما:

• تحتاج أحداث المنتج والتجارة الإلكترونية إلى التدفق نحو Brevo.
• يجب أن تُحفّز بيانات Shopify أو بيانات تجارية أخرى مراسلة السلة المتروكة أو الطلبات أو دورة الحياة.
• تريد طبقة تكامل واحدة لبيانات العملاء والطلبات والمنتجات والأحداث.
• تحتاج إلى مسار موثّق للمراسلة التشغيلية متصل بنموذج بيانات العملاء الأوسع لديك.

لا ينبغي أن تحل Tajo محل مرجع API الخاص بالمزود. بل يجب أن تقلّل من عمل التكامل اللازم لإدخال بيانات العملاء والأحداث الصحيحة إلى نظام المراسلة.

متى تستخدم API البريد الإلكتروني

الرسائل التشغيلية

تُحفَّز الرسائل التشغيلية بإجراء من المستخدم أو حدث في النظام.

أمثلة:

• التحقق من الحساب.
• تسجيل الدخول برابط سحري.
• إعادة تعيين كلمة المرور.
• المصادقة الثنائية.
• دعوة للمنتج.
• تأكيد الطلب.
• إيصال الدفع.
• تأكيد الشحن.
• تحديث التوصيل.
• إشعار الاسترداد.
• تجديد الاشتراك.
• تنبيه فشل الدفع.
• إشعار أمني.

للبريد التشغيلي توقعات عالية من الموثوقية. يلاحظ المستخدمون فورًا عندما لا يصل رابط تسجيل الدخول، أو إيصال الطلب، أو رسالة إعادة تعيين كلمة المرور.

طالع أيضًا: رسائل تأكيد الطلب وأمثلة على البريد التشغيلي.

رسائل دورة حياة المنتج

تقع رسائل دورة الحياة بين البريد التشغيلي والتسويقي.

أمثلة:

• تهيئة التجربة المجانية.
• تفعيل الميزة.
• إنجاز في الاستخدام.
• اقتراح ترقية.
• تذكير بالحساب غير النشط.
• متابعة من نجاح العملاء.
• تسلسل التجديد.
• رسالة استعادة.

تعمل هذه الرسائل بأفضل شكل عندما تُحفّزها بيانات المنتج، لا جدول زمني عام.

رسائل التجارة الإلكترونية

غالبًا ما تحتاج فرق التجارة الإلكترونية إلى بريد إلكتروني تشغيلي وآخر يُحفّزه التسويق:

• عرض ترحيبي.
• السلة المتروكة.
• ترك التصفح دون شراء.
• توفر مجددًا في المخزون.
• انخفاض السعر.
• توصية بمنتج.
• تذكير بإعادة التزويد.
• تحديث الولاء.
• طلب مراجعة.
• وصول مبكر لعملاء VIP.

بالنسبة لفرق Shopify وBrevo، يمكن لـTajo أن تساعد في ربط بيانات الطلبات والعملاء والموافقة والمنتجات والسلة، بحيث تُحفَّز هذه الرسائل بسلوك تجاري فعلي.

الرسائل التسويقية عبر API

لا تتعامل مع البريد التسويقي كمهمة نشرة جماعية فقط.

يمكن أن يدعم التسويق الذي تُحفّزه API:

• تقسيمًا إلى شرائح مبنيًا على الأحداث.
• حملات مخصصة.
• تسلسلات بالتنقيط مُحفَّزة.
• تهيئة يقودها المنتج.
• رحلات دورة حياة مبنية على الحساب.
• بريدًا إلكترونيًا آليًا مرتبطًا بسلوك العميل.

لا يزال معيار الامتثال قائمًا. تحتاج الرسائل التسويقية إلى موافقة مناسبة، والتعامل مع إلغاء الاشتراك، وقواعد الإيقاف.

أهم ميزات API التي يجب البحث عنها

المصادقة وإدارة المفاتيح

ينبغي أن يدعم أي API بريد إلكتروني جاد مفاتيح API آمنة وتوثيق مصادقة واضح.

متطلبات تشغيلية:

• فصل المفاتيح حسب البيئة.
• تقييد الوصول إلى مفاتيح الإنتاج.
• تدوير المفاتيح.
• تخزين المفاتيح خارج الكود.
• تسجيل استخدام المفتاح دون تسجيل قيمته.
• إزالة المفاتيح من مخرجات الطلبات الفاشلة.

القوالب

تحافظ القوالب على اتساق البريد التشغيلي.

ابحث عن:

• إصدار النسخ (versioning).
• إرسالات اختبارية.
• المتغيرات.
• القيم الاحتياطية.
• الترجمة والتوطين.
• عرض المعاينة.
• سير عمل الموافقة.
• فصل قوالب بيئة الاختبار عن الإنتاج.

القوالب ليست مجرد أصول تصميم، بل هي جزء من عقد المنتج. يجب مراجعة قالب إعادة تعيين كلمة المرور، وقالب تأكيد الطلب، وقالب الفاتورة، بالجدية نفسها التي تُراجَع بها واجهة التطبيق.

Webhooks

تحوّل Webhooks الإرسال إلى حلقة تغذية راجعة.

تتبّع:

• تمت المعالجة.
• مؤجَّل.
• تم التسليم.
• تم الفتح، بحذر.
• تم النقر، بحذر.
• ارتد.
• أُسقط.
• شكوى.
• إلغاء الاشتراك.

خزّن معرّفات رسائل المزود، بحيث يمكن مطابقة أحداث Webhooks بالمستخدمين والأحداث الداخلية.

إدارة الإيقاف

تحمي معالجة الإيقاف القدرة على التسليم والامتثال.

يجب أن يتعامل النظام مع:

• الارتدادات الصلبة (hard bounces).
• الشكاوى.
• حالات إلغاء الاشتراك.
• الحظر اليدوي.
• العناوين المبنية على الأدوار إذا كانت سياستك تستبعدها.
• جهات الاتصال غير الصالحة.
• طلبات حذف الحساب أو الخصوصية.

لا تستمر أبدًا في إعادة المحاولة مع عنوان فشل بشكل دائم، لمجرد أن كود المنتج يرى “إرسال البريد” كمهمة خلفية فقط.

حدود المعدل والإنتاجية

تحقّق من كيفية تعامل المزود مع:

• حدود طلبات API.
• إنتاجية الرسائل.
• نقاط نهاية الدفعات.
• حدود الاندفاع (burst).
• حدود الخطة اليومية أو الشهرية.
• تسخين الحساب الجديد.
• تسخين عنوان IP المخصص.

خطّط لذروات الاستخدام. يمكن أن يخلق إطلاق منتج، أو حادثة إعادة تعيين كلمات مرور، أو تخفيضات الجمعة السوداء، أو إشعار أمني، حجم إرسال أعلى بكثير من المتوسط اليومي.

التحليلات والتصدير

الحد الأدنى من التقارير:

• تم الإرسال.
• تم التسليم.
• ارتد.
• مؤجَّل.
• الشكاوى.
• حالات إلغاء الاشتراك.
• أداء القالب.
• أخطاء استجابة المزود.
• أحداث الإيرادات أو التحويل عند اللزوم.

تعامل مع معدلات الفتح والنقر بحذر. يمكن أن تشوّه حماية الخصوصية، وحظر الصور، ونشاط الروبوتات مقاييس التفاعل. بالنسبة للبريد التشغيلي، غالبًا ما يكون التسليم ونجاح إجراء المستخدم أهم من معدل الفتح.

تحليل البريد الوارد

يهم البريد الوارد عندما يرد المستخدمون أو يرسلون محتوى إلى المنتج.

حالات استخدام:

• ردود الدعم.
• تحويل البريد إلى تذكرة.
• الرد على تعليق.
• سير عمل الموافقة.
• إيصالات مُعاد توجيهها.
• جمع العملاء المحتملين الواردين.

إذا كان تحليل البريد الوارد جزءًا من خارطة الطريق، اختر مزودًا بتوثيق واضح، وتوجيه، وضوابط أمان، ومعالجة للمرفقات.

القدرة على التسليم مع API البريد الإلكتروني

لا تحل API القدرة على التسليم تلقائيًا.

لا تزال تحتاج إلى:

• SPF.
• DKIM.
• DMARC.
• نطاقات إرسال موثّقة.
• هوية مرسل متسقة.
• قوائم نظيفة.
• التعامل مع الارتداد.
• التعامل مع الشكاوى.
• إلغاء اشتراك واضح للرسائل التسويقية.
• محتوى ذو صلة.
• تكرار إرسال معقول.
• المراقبة.

بالنسبة للنطاقات أو عناوين IP الجديدة، سخّنها تدريجيًا. ابدأ ببريد منخفض المخاطر وعالي التفاعل، وزد الحجم مع استقرار السمعة.

افصل بين أنواع الرسائل كلما أمكن:

• المصادقة والأمان.
• الإيصالات وتحديثات الطلبات.
• دورة حياة المنتج.
• التسويق.
• العروض الترويجية الجماعية.

لا تدع حملة ترويجية عدوانية تضر بتسليم رسائل إعادة تعيين كلمة المرور أو الإيصالات.

معالجة الأخطاء وإعادة المحاولات

ينبغي تصنيف إخفاقات API البريد الإلكتروني.

أعد المحاولة مع:

• انتهاء المهلة.
• خطأ مؤقت من المزود.
• تجاوز حد المعدل بعد تأخير.
• فشل الشبكة.
• مشكلة مؤقتة في قائمة الانتظار.

لا تعد المحاولة إلى الأبد مع:

• عنوان مستلم غير صالح.
• مفتاح API غير مصرّح به.
• معرّف قالب غير صالح.
• حقل مطلوب مفقود.
• مستلم مُوقَف.
• حظر بسبب السياسة أو الامتثال.

استخدم التراجع الأسي (exponential backoff) وقائمة انتظار للرسائل الميتة (dead-letter queue) للرسائل التي لا تزال تفشل بعد إعادة المحاولات.

يجب أن يكون لكل بريد إلكتروني حرج مسار تشغيلي:

• هل يمكن للدعم إعادة إرساله؟
• هل يمكن للمستخدم طلبه مجددًا؟
• هل يمكن للهندسة تتبّع الحدث؟
• هل يمكنك رؤية استجابة المزود؟
• هل يمكنك إثبات ما إذا كان المزود قد قبِله؟

قائمة تحقّق لتنفيذ API البريد الإلكتروني

استخدم قائمة التحقّق هذه قبل الإطلاق.

1. حدّد أنواع الرسائل وملكيتها.
2. اختر مزود API ونهج الخطة البديلة.
3. وثّق نطاقات المرسل.
4. اضبط SPF وDKIM وDMARC.
5. أنشئ مفاتيح API لبيئتي الاختبار والإنتاج.
6. خزّن الأسرار بأمان.
7. ابنِ خدمة رسائل أو طبقة تكيّف.
8. أضف مفاتيح التماثل التكراري.
9. أضف سجلات منظّمة.
10. ابنِ سلوك إعادة المحاولة وقائمة الانتظار الميتة.
11. أنشئ القوالب.
12. افحص جودة التخصيص والقيم الاحتياطية.
13. اضبط Webhooks.
14. خزّن معرّفات رسائل المزود.
15. عالج الارتدادات والشكاوى وإلغاء الاشتراك.
16. ابنِ أدوات دعم لإعادة الإرسال والاستعلام عن الحالة.
17. راقب معدلات الأخطاء والتسليم.
18. وثّق حدود المعدل وخطط التعامل مع الحوادث.

بطاقة تقييم اختيار المزود

قيّم كل مزود من 1 إلى 5:

بالنسبة للعديد من الفرق، الإجابة الصحيحة ليست “أرخص API للبريد الإلكتروني”، بل المزود الذي يقلّل المخاطر التشغيلية لأنواع البريد التي يعتمد عليها العملاء.

الأخطاء الشائعة

تجنّب:

• الإرسال مباشرةً من كود تطبيق متناثر.
• تسجيل مفاتيح API أو حمولات كاملة تحتوي على بيانات خاصة.
• إعادة المحاولة مع كل خطأ وكأنه مؤقت.
• تجاهل معرّفات رسائل المزود.
• نسيان Webhooks إلى أن يسأل الدعم “هل وصل البريد الإلكتروني؟”.
• خلط رسائل إعادة تعيين كلمة المرور بالتسويق الجماعي على مسار السمعة نفسه.
• استخدام قالب واحد لكل لغة.
• تخطي القيم الاحتياطية لمتغيرات القالب.
• اعتبار معدلات الفتح دليلًا على التسليم أو نجاح العميل.
• السماح لمنطق إلغاء اشتراك التسويق بإيقاف رسائل أمان الحساب الإلزامية دون سياسة متعمدة.
• مقارنة المزودين بناءً على الفئة المجانية فقط.
• إطلاق حجم كبير دون تسخين.

البدء

بالنسبة لتنفيذ جديد، اتّبع أقصر مسار آمن:

1. ابدأ برسالة تشغيلية واحدة، مثل إعادة تعيين كلمة المرور أو تأكيد الطلب.
2. ابنِ طبقة تكيّف للمزود بدلًا من ربط كود المنتج بمزود واحد.
3. أضف مصادقة النطاق.
4. أضف تتبّع الحالة عبر Webhooks.
5. أضف رؤية للدعم.
6. أضف القوالب والترجمة.
7. توسّع إلى أتمتة دورة الحياة والتجارة الإلكترونية.

إذا كان فريقك يستخدم Brevo بالفعل للتسويق وCRM، ابدأ بـAPI البريد التشغيلي من Brevo وحدّد بيانات الأحداث التي تحتاجها. إذا كان منتجك يحتاج إلى تدفق بيانات التجارة الإلكترونية إلى Brevo، استخدم Tajo لربط أحداث العملاء والموافقة والمنتجات والسلة والطلبات قبل بناء مزيد من مراسلة دورة الحياة.

لإعداد SMTP بدلًا من ذلك، راجع دليل SMTP الشامل ودليل خادم SMTP المجاني.

أدلة ذات صلة

• دليل خدمة البريد التشغيلي
• أمثلة على البريد التشغيلي
• دليل SMTP الشامل
• SPF وDKIM وDMARC
• دليل أتمتة البريد الإلكتروني
• تكامل Brevo وShopify