واجهات API للبريد متوافقة مع Resend: ما الذي لا يشمله التوافق

ماذا يعني توافق API فعلًا

For email developers, Resend-compatible mail APIs implement the same request and response schemas as the provider they replace. If you use a Resend-compatible API, you can change your base URL and API key in your environment variables and your POST /emails calls will still work. It covers the syntax of the payload, the HTTP status codes, and the structure of the JSON response. It does not cover your sender reputation, your DNS configuration, your IP warm up, or your billing structure.

بصفتي مهندسًا يدير طابور الحوادث، رأيت فرقًا تفترض أن «التوافق» يعني ترحيلًا بنقرة واحدة. وهو ليس كذلك. أنت ترحّل الواجهة لا البنية التحتية.

الواجهة: ما الذي يغطيه التوافق

عندما يدّعي مزوّد التوافق مع Resend، فهو عادةً يحاكي نقطة نهاية الإرسال الأساسية. وهذا يتيح لك إرسال حمولة كهذه:

{ "from": "onboarding@example.com", "to": "user@gmail.com", "subject": "Welcome to the App", "html": "<strong>Hello!</strong>" }

إذا كانت واجهة API متوافقة، فسيعيد الخادم 200 OK أو 201 Created مع معرّف الرسالة. وهذا هو الجزء «السهل». فهو يعفيك من إعادة كتابة منطق التكامل أو تغيير SDK. وبالنسبة إلى الفرق التي تبني وكلاء ذكاء اصطناعي، فهذا الاتساق حيوي. فعندما تُطلق الوكلاء الرسائل عبر خادم MCP أو بطاقة A2A، فإنها تعتمد على مخططات متوقَّعة للتحقق من وقوع الأثر الجانبي (إرسال الرسالة) فعلًا.

البنية التحتية: ما الذي لا يغطيه التوافق

ينتهي التوافق عند طبقة HTTP. وكل ما يحدث بعد قبول واجهة API للطلب خاص بالمزوّد.

1. DNS وتوثيق النطاق

مفتاح API لا يحمل تفويض نطاقك. ولا يمكنك ببساطة تبديل عناوين URL وتتوقع أن تكون رسائلك موثَّقة. يجب أن توثّق نطاقك من جديد لدى المزوّد الجديد. ويتضمن ذلك إضافة سجلات SPF وDKIM وDMARC جديدة إلى DNS.

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

2. سمعة المُرسِل وإحماء IP

ترتبط السمعة بعنوان IP المُرسِل والنطاق. وإذا انتقلت من مزوّد إلى آخر، فأنت غالبًا تنتقل إلى مجموعة جديدة من عناوين IP المشتركة. وحتى لو كانت لنطاقك سمعة ممتازة، فقد يكون عنوان IP الجديد «باردًا» أو، وهو الأسوأ، مشتركًا مع جهة سيئة.

قبول المزوّد (أن تقول واجهة API «OK») يختلف عن التسليم (قبول الخادم المستلِم للبريد)، وهو يختلف بدوره عن الوصول إلى صندوق الوارد (وصول الرسالة إلى المجلد الرئيسي). ويغطي التوافق قبول المزوّد فقط. ولا يفعل شيئًا للتسليم أو الوصول.

3. webhooks ومخططات الأحداث

قد تكون واجهة الإرسال متوافقة، لكن أحداث webhook (delivered وbounced وcomplained) غالبًا لا تكون كذلك. وإذا كان نظامك يعتمد على تتبع أحداث التسليم لتشغيل منطق المتابعة، فيجب أن تدقق حمولات webhook لدى المزوّد الجديد. فقد يكون حدث bounce في نظام هو hard_bounce في نظام آخر.

تكلفة التوافق: واقع الأسعار

يتيح لك التوافق البحث عن أسعار أفضل دون تكلفة إعادة كتابة كاملة. غير أن نماذج التسعير تتفاوت تفاوتًا كبيرًا. استنادًا إلى بيانات سبتمبر 2026:

• Amazon SES: التسعير الأكثر جرأة. يكلّف نموذج a la carte ما مقداره 0.10 USD لكل 1,000 رسالة (أسعار Amazon SES). وتشمل الباقات المتدرجة الجديدة التي أُطلقت في 21 يوليو 2026 باقة Essentials (0.16 USD لكل 1,000)، وPro (0.22 USD لكل 1,000 مع 105 USD شهريًا لكل منطقة)، وEnterprise (0.23 USD لكل 1,000 مع 500 USD شهريًا).
• Resend: تقدّم باقة مجانية بـ 3,000 رسالة شهريًا (بحد أقصى 100 يوميًا). وباقة Pro بـ 20 USD شهريًا لـ 50,000 رسالة، مع رسوم تجاوز قدرها 0.90 USD لكل 1,000 (أسعار Resend).
• Postmark: 15 USD شهريًا لـ 10,000 رسالة، مع رسوم تجاوز بين 1.80 و1.20 USD لكل 1,000 (أسعار Postmark).
• Mailgun: 15 USD شهريًا لـ 10,000 رسالة، مع رسوم تجاوز بين 1.80 و1.10 USD لكل 1,000 (أسعار Mailgun).
• SendGrid: الباقة المجانية أصبحت الآن فترة تجريبية مدتها 60 يومًا، وتبدأ Essentials من 19.95 USD شهريًا (أسعار SendGrid).

لوضع ذلك في منظوره: يكلّف إرسال 50,000 رسالة نحو 5 USD على SES بنموذج a la carte، ونحو 66 USD على باقات Postmark. ويتيح توافق API هذا التحسين في التكلفة دون شهر من العمل الهندسي.

الهندسة للموثوقية وللوكلاء

عندما تتعامل مع البريد كأثر جانبي خارجي، خصوصًا عند استخدام وكلاء الذكاء الاصطناعي، يجب أن تحسب حساب الفشل. فإعادة واجهة API لـ 200 OK لا تعني أن الرسالة وصلت إلى المستخدم.

عدم التكرار

إذا أعاد وكيل محاولة طلب بسبب انتهاء المهلة، فأنت تخاطر بإرسال الرسالة نفسها مرتين. وهذه تجربة مستخدم سيئة. ينبغي أن تستخدم مفتاح عدم التكرار (idempotency key) في ترويساتك. وهذا يضمن أنه إذا أُرسل الطلب نفسه مرتين، فلن يرسل المزوّد إلا رسالة واحدة.

سير عمل الموافقة

لا ينبغي أن تحصل الوكلاء على وصول غير مقيَّد إلى حصة الإرسال لديك. طبّق طبقة موافقة على عمليات الإرسال عالية الحجم. وفيما يلي قائمة تحقق بسيطة للبريد الذي تقوده الوكلاء:

1. التحقق من المخطط: هل تطابق الحمولة مواصفات API المتوافقة؟
2. حد المعدّل: هل يتجاوز الوكيل السقف اليومي (مثل حد Resend المجاني البالغ 100 يوميًا)؟
3. عدم التكرار: هل يوجد مفتاح فريد لهذه المعاملة تحديدًا؟
4. إشراك الإنسان في الحلقة: هل تتطلب هذه الرسالة موافقة يدوية قبل استدعاء API؟

قائمة التحقق للترحيل

إذا كنت تنتقل إلى مزوّد متوافق مع Resend، فاتبع هذا التسلسل لتجنب انهيار التسليم:

• إعداد DNS: هيئ SPF وDKIM وDMARC. اقرأ دليلنا حول مصادقة البريد الإلكتروني لتتأكد من عدم فقدان أي سجلات.
• التحقق: استخدم أداة لتأكيد انتشار DNS.
• الإحماء: إذا كنت ترسل أحجامًا كبيرة، فانقل حركة المرور تدريجيًا من المزوّد القديم إلى الجديد. لا تنقل 100% من حركة المرور في ساعة واحدة.
• تدقيق webhook: عيّن أنواع أحداث المزوّد الجديد إلى مخططات قاعدة بياناتك الداخلية.
• معالجة الأخطاء: اختبر كيفية تعامل المزوّد الجديد مع رسائل البريد الإلكتروني غير الصالحة. هل يعيد 400 أم 202 مع حدث ارتداد لاحق؟

ملخص المفاضلات

الجانب | هل يغطيه التوافق؟ | الإجراء المطلوب

حمولة الطلب | نعم | لا شيء (إذا طابقت المواصفات)

صيغة الاستجابة | نعم | لا شيء (إذا طابقت المواصفات)

مصادقة النطاق | لا | حدّث سجلات DNS

سمعة IP | لا | فترة إحماء

الأسعار/الحصص | لا | راجع صفحات أسعار المزوّد

أحداث webhook | لا | حدّث مستمعي الأحداث

التوافق أداة للمرونة، وليس عصا سحرية لقابلية التسليم. وبفصل الواجهة عن البنية التحتية، يمكنك التحسين من حيث التكلفة والأداء دون أن تقيّد نفسك بمنظومة مزوّد واحد.

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