Resend خدمة بريد للمطورين تتيح إرسال رسائل التطبيق عبر API، مثل تأكيد التسجيل وإعادة تعيين كلمة المرور وإشعار الطلب. وتدعم أيضا حملات Broadcasts، لكن الرسالة المرتبطة بحدث داخل التطبيق ليست هي الحملة التسويقية. اختيار النوع الصحيح يبدأ قبل كتابة الكود.
ماذا تحتاج قبل إرسال أول إيميل؟
تذكر وثائق Resend عنصرين أساسيين: دومينا تملكه وتتحقق منه داخل الخدمة، ومفتاح API. تحتاج كذلك وصولا إلى إعدادات DNS لإضافة السجلات المطلوبة، وعنوان إرسال واضحا، وبيئة خلفية تحفظ المفتاح بعيدا عن كود المتصفح. استخدام مكتبة رسمية قد يقلل تفاصيل المصادقة ومعالجة الأخطاء التي ستكتبها بنفسك.
تجهيز الدومين خطوة بخطوة
1. أضف الدومين الصحيح في لوحة Resend، بعد التأكد من امتلاكك صلاحية تعديل DNS.
2. انسخ سجلات التحقق التي يعرضها حسابك كما هي إلى مزود DNS. لا تنقل قيما من مثال عام أو حساب آخر.
3. انتظر التحقق وراجع حالة السجلات، بدلا من افتراض أن حفظها يعني انتشارها فورا.
4. اختر عنوان المرسل من الدومين المتحقق، واختبر الرد عليه إذا كان العملاء سيستخدمونه.
5. راجع إعدادات المصادقة في الوثائق، بما فيها SPF وDKIM، قبل تشغيل الإرسال الحقيقي.
مثال تدفق: تأكيد طلب داخل تطبيق
بعد تسجيل الطلب في قاعدة البيانات، ينشئ الخادم رسالة تأكيد ويرسلها من خلال Resend. احتفظ بمعرف الرسالة وحالة الإرسال في نظامك، واربطها بمعرف الطلب. لا ترسل الرسالة من الواجهة مباشرة باستخدام مفتاح سري، ولا تجعل إعادة تحميل صفحة النجاح ترسل نسخة جديدة كل مرة.
أين تضع مفتاح API؟
ضعه في متغير بيئة على الخادم، وليس في مستودع عام أو ملف JavaScript يصل إلى الزائر. استخدم نطاق الصلاحية الذي يحتاجه التطبيق، وافصل بين بيئة الاختبار والإنتاج قدر الإمكان. إذا انكشف المفتاح، ألغِه واستبدله؛ إخفاؤه من آخر نسخة للكود لا يلغي نسخة سبق نشرها.
كيف تتجنب الرسائل المكررة؟
قد تنجح عملية الإرسال ثم ينقطع اتصال التطبيق قبل وصول الرد. إعادة الطلب بلا ضابط قد ترسل رسالتين. تدعم Resend مفاتيح Idempotency للإرسال، لتتعامل مع إعادة المحاولة للعملية نفسها. صمم المفتاح حول حدث محدد مثل تأكيد طلب بعينه، وراجع نافذة الصلاحية وسلوك المفتاح في الوثائق. ولا تستخدم المفتاح نفسه لكل الرسائل المختلفة.
هل استجابة API تعني وصول الرسالة للصندوق الوارد؟
لا. قبول طلب الإرسال مرحلة، ووصول الرسالة مرحلة أخرى، وظهورها في البريد الوارد يتأثر بعوامل لا يحسمها نجاح الطلب وحده. تتيح Webhooks متابعة أحداث البريد وربطها بتطبيقك. صمم معالجة الأحداث بحيث تتحقق من المصدر وتتحمل إعادة التسليم، ولا تعرض للمستخدم حالة مؤكدة قبل أن تتوافر لديك الأدلة المناسبة.
رسائل التطبيق أم Broadcasts؟
تأكيد الحساب أو إيصال الطلب عادة رسالة معاملات مرتبطة بحدث يخص شخصا محددا. أما نشرة العروض إلى قائمة مشتركين فهي حملة تسويقية تحتاج أساسا صحيحا للاشتراك وإدارة إلغاء الاشتراك. لا تحول قائمة مستخدمي التطبيق تلقائيا إلى قائمة تسويق، ولا تختَر الخطة اعتمادا على رقم إجمالي دون تمييز نوع الإرسال.
قائمة اختبار قبل الإطلاق
• اختبر الرسالة على الهاتف وعلى أكثر من مزود بريد.
• جرّب عنوانا خاطئا وفشل الإرسال، وتأكد أن التطبيق لا يخفي الخطأ.
• اختبر إعادة المحاولة دون تكرار الرسالة.
• راجع الروابط والنص البديل والمعلومات الشخصية داخل القالب.
• راقب حدود الإرسال الفعلية وحالات الرفض، وضع مسارا للدعم عند الحاجة.
كيف تختار اشتراك Resend؟
راجع حجم رسائل التطبيق المتوقع وحدود الخطة ومعدل الإرسال واحتياجك للحملات بصورة منفصلة. لا تفترض أن كلمة اشتراك تعني إرسالا غير محدود أو ضمان الوصول إلى Inbox. وتحقق من ملكية الدومين والحساب وطريقة إدارة المفاتيح قبل ربط الخدمة بعملك.
قبل طلب الاشتراك من AI Friend Tools
توضح صفحة Resend بالمتجر نوع المنتج. اسأل عن الخطة ونطاق التفعيل وما تحتاج تجهيزه بنفسك، ولا تشارك مفتاح API في رسالة شراء أو تذكرة دعم عادية.
المصادر الرسمية
مدخل الخدمة ومتطلبات البدء:
التحقق من الدومين:
مفاتيح منع تكرار الطلب:
متابعة أحداث البريد:
الخطط الحالية:
راجعت المصادر في 25 أكتوبر 2026. الحدود وإجراءات الإعداد قابلة للتغيير.