الانتقال إلى المحتوى الرئيسي
عميل PHP الرسمي لواجهة برمجة تطبيقات Nateq. نواة مستقلة عن أُطر العمل، مع مزوّد خدمة (service provider) وواجهة Nateq يُكتشفان تلقائياً في Laravel. بدون أي اعتماديات مطلوبة وقت التشغيل، لذا لن يتعارض مع إصدار Guzzle في تطبيقك.

Packagist

nateq/sdk

GitHub

الكود المصدري والمشكلات

المتطلبات

  • PHP الإصدار 8.2 أو أحدث
  • الامتدادان ext-curl و ext-json
  • Laravel 11 أو 12 (اختياري — تعمل الحزمة بدونه)

التثبيت

في Laravel، يُكتشف مزوّد الخدمة وواجهة Nateq تلقائياً. لا شيء تحتاج لتسجيله.

البدء السريع

أنشئ مفتاح API بنطاق emails:send، ثم ضعه في بيئتك:
في Laravel، احصل على العميل من الحاوية بدلاً من إنشائه:

المصادقة

تقرأ الحزمة NATEQ_API_KEY افتراضياً. مرّره صراحةً لتحميله من مدير أسرار، أو للتعامل مع أكثر من مؤسسة:
يتم التحقق من المفتاح محلياً قبل أي طلب، لذا يفشل المفتاح الخاطئ فوراً بدلاً من إرساله عبر الشبكة.
تُخفي var_dump() و json_encode() وصفحات أخطاء أُطر العمل المفتاحَ، كما أن محاولة تسلسل (serialize) العميل تُطلق خطأً عن قصد. لكن print_r() و var_export() لا تملكان أي آلية إخفاء في PHP وستطبعان المفتاح — لا تمرّر العميل إلى أي منهما.

إرسال البريد الإلكتروني

تعود send() بمجرد قبول الواجهة للرسالة. أما التسليم فيحدث بعد ذلك — العودة بنجاح تعني أن Nateq تحمّلت مسؤولية الرسالة، لا أنها وصلت.
قدّم htmlBody أو plainTextBody أو كليهما. احذف fromEmail و emailAddressId لاستخدام عنوان مؤسستك الافتراضي المُوثَّق.

قراءة البريد الإلكتروني

EmailStatus هو تعداد (enum) مزوّد بدوال مساعدة، حتى لا تحفظ أي من الحالات التسع يُعدّ نجاحاً:
اعرض قائمة الرسائل المُرسلة، الأحدث أولاً. النتيجة قابلة للعدّ والتكرار:
القيمة الافتراضية لـ limit هي 50 والحد الأقصى 100.
تُرجع الواجهة حقولاً أكثر مما تمثّله الحزمة. أي حقل غير مُتاح كخاصية يبقى موجوداً في $email->raw، لذا يعمل الحقل الجديد دون ترقية الحزمة.

الأخطاء

كل الأخطاء ترث من NateqException، لذا تكفي كتلة catch واحدة:
راجع الأخطاء لرموز الواجهة الأساسية.

إعادة المحاولة والإرسال المُكرر

تُعاد عمليات القراءة (get و list) تلقائياً عند انتهاء المهلة أو أخطاء 5xx أو فشل الاتصال، مع تراجع تدريجي يحترم Retry-After. أما send() فلا. لا تملك الواجهة مفتاح تكرار (idempotency key)، لذا فإن عملية إرسال تفشل بعد وصولها إلى الخادم قد تكون قد أُرسلت فعلاً. إعادتها قد تُرسل رسالتين إلى عميلك، والحزمة لن تتخذ هذا القرار نيابةً عنك. الاستثناء هو 429، الذي تُطلقه الواجهة قبل إرسال أي شيء — لذا تُعاد المحاولة، لأن التكرار مستحيل. إذا أطلقت send() خطأ TimeoutException أو ServerException، فالنتيجة غير معروفة فعلاً. تحقق منها قبل إعادة المحاولة:

Laravel

انشر ملف الإعدادات فقط إذا أردت تعديله:
احقن العميل، أو استخدم الواجهة (facade):

الإرسال من مهمة في الطابور

البريد الإلكتروني هو استدعاء شبكي لطرف ثالث. تنفيذه داخل الطلب يربط زمن استجابتك بزمن استجابتنا.
احصل على العميل عبر handle() كما في الأعلى — ولا تخزّنه أبداً كخاصية في المهمة. تُسلسَل خصائص المهمة داخل حمولة الطابور، والعميل يرفض التسلسل تحديداً حتى لا ينتهي مفتاح API الخاص بك مخزّناً في Redis كنص صريح.
إذا غيّرت NATEQ_API_KEY ولم يحدث شيء، فلديك إعدادات مُخزّنة مؤقتاً:

الاختبار

لا تستدعِ الواجهة الحقيقية من مجموعة اختباراتك. نفّذ HttpClient بنسخة وهمية:
في Laravel، اربطها في الحاوية وسيلتقطها العميل — بما في ذلك عبر الواجهة (facade):
نفس هذه النقطة تتيح توجيه الطلبات عبر منظومتك الخاصة — Guzzle أو Symfony HttpClient أو وكيل صادر (proxy).