واجهة API للإرسال الجماعي في واتساب وتيليجرام

واجهة API للإرسال الجماعي في واتساب وتيليجرام: اربط الحساب، وأنشئ الحملة، واستلم حالات الإرسال مباشرة في نظام CRM لديك أو على موقعك.

نادرًا ما تحتمل رسائل العملاء التأجيل «إلى أن يتسع الوقت». موعدها لحظة وقوع الحدث: دفع العميل ثمن الطلب، حجز موعدًا، لم يحضر، غاب شهرًا كاملًا. وما دام الحدث قد سُجّل في نظامك، فمن الغريب أن تدخل بعده لوحة التحكم لتُعدّ الحملة يدويًا.

لهذا وُجدت واجهة API العامة. تمرّ عبرها الحملة كاملة: جمع الجمهور، وفحص النص، والوتيرة الآمنة، وحالة كل مستلم وردّه. لا تحتاج إلى بناء طابور، ولا إلى ضبط الفواصل بين الرسائل، ولا إلى إعادة المحاولات، ولا إلى حماية الرقم من الحظر: هذا كله تتولاه الخدمة، ويبقى في نظامك استدعاء واحد.

ومجموعة نقاط النهاية واحدة للجميع: حسابات واتساب وتيليجرام، وبوتات تيليجرام. ولإضافة تطبيق مراسلة آخر لا تكتب تكاملًا جديدًا: يكفي تغيير قيمة واحدة في الطلب نفسه.

ما الذي تستطيعه واجهة API للإرسال الجماعي في واتساب وتيليجرام

كل ما تفعله يدويًا في لوحة التحكم متاح عبر HTTP:

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

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

كيف تحصل على مفتاح API

1. ادخل لوحة التحكم وافتح قسم API.
2. اضغط «إنشاء مفتاح»، وأعطه اسمًا (ليتضح منه لاحقًا لأي تكامل أُصدر المفتاح)، وحدّد مدة صلاحيته إن أردت.
3. انسخ الرمز. يُعرض مرة واحدة فقط: تحتفظ الخدمة ببصمته (hash) وحدها ولا تستطيع استعادة قيمته. إن ضاع منك، أنشئ مفتاحًا جديدًا واحذف القديم.

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

يصدر المفتاح للمشروع ولا يرتبط بموظف بعينه. احفظه كما تحفظ كلمة المرور. ويمكن إنشاء عدة مفاتيح، مثلًا مفتاح لكل تكامل، لتُلغي كلًّا منها بمعزل عن غيره.

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

يُمرَّر الرمز في ترويسة كل طلب. وللتأكد من أن كل شيء يعمل، اطلب قائمة الحسابات المتصلة:

curl https://api.wsender.io/v1/channel \
  -H "Authorization: key YOUR_TOKEN"

جميع نقاط النهاية موصوفة في توثيق API، ويمكنك تنفيذ أي طلب بمفتاحك من المتصفح مباشرة دون كتابة سطر برمجي واحد. وإلى جانبه مواصفات قابلة للقراءة الآلية، هي ملف OpenAPI: تولّد منه أدوات مثل Swagger Codegen أو NSwag عميلًا بلغتك البرمجية تلقائيًا، فلا تحتاج إلى وصف الطلبات والنماذج يدويًا.

حملة في سبعة طلبات

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

1. PUT /v1/segment ينشئ الشريحة.
2. PUT /v1/segment/{segmentId}/contact يرفع الأرقام.
3. PUT /v1/mailing ينشئ الحملة.
4. PUT /v1/mailing/{mailingId}/message/text يضيف نص الرسالة.
5. PUT /v1/mailing/{mailingId}/recipient/source يحدّد أن المستلمين يؤخذون من الشريحة.
6. POST /v1/mailing/{mailingId}/moderate يرسل النص إلى المراجعة.
7. POST /v1/mailing/{mailingId}/start يطلق الإرسال من الحساب المختار.

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

تكرار الطلب لا ينشئ حملة ثانية

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

لذلك يحمل كل طلب يغيّر شيئًا مفتاحَ تكرار. تختار سلسلة نصية (عادة UUID) وتمرّرها في الترويسة:

Idempotency-Key: 3f0c1b7e-8a2e-4a51-9d2b-6a1e0f2c4d88

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

وإن أرسلت طلبًا مختلفًا بالمفتاح نفسه، يصلك الرد 422. هذه حماية من إعادة استخدام المفتاح عن طريق الخطأ: لن تحصل على نتيجة طلب آخر.

الخلاصة العملية للتكامل: كرّر الطلبات التي لم تصلك نتيجتها: عند انقطاع الاتصال، وأخطاء الخادم، والرد 429 (تجاوز معدل الطلبات). هذه الردود لا تُحفظ، والتكرار سينفّذ العملية فعلًا. أما الرفض لسبب جوهري، مثل «في النص حقل إلزامي ناقص»، فهو نتيجة بحد ذاته، والتكرار سيعيده كما هو.

من أين تأتي بالمستلمين

الخطوة الخامسة تستحق وقفة خاصة: فعلى المصدر تتوقف النتيجة ومستوى المخاطرة على الحساب معًا. والمصادر ثلاثة.

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

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

بوتات تيليجرام: واجهة API نفسها

لا توجد لدينا «API للبوتات» منفصلة، وهذا مقصود: التكامل المكتوب للإرسال من حساب مراسلة يعمل مع البوت دون تعديل. طرق الربط نفسها، والحالات نفسها، والويب هوك نفسه، والمسار نفسه للحملة من المسودة إلى تقرير المستلمين.

الفرق في أمرين فقط، وكلاهما يظهر من البداية.

الربط برمز البوت. تحصل على الرمز (token) من تيليجرام نفسها، إذ يصدره @BotFather. بعدها ترسل طلب الربط نفسه الذي ترسله للحساب، لكن مع الرمز بدل طريقة تسجيل الدخول. وإن أعدت إصدار الرمز فلن تفقد البوت: طلب مستقل لتحديث الرمز يغيّره في البوت المتصل، ويبقى المشتركون والحملات والسجل في مكانها (وفي لوحة التحكم يفعل الرابط «تحديث الرمز» في صفحة البوت الشيء نفسه).

المستلمون: مشتركو البوت. يكتب البوت لمن كتب إليه بنفسه، وشريحة الأرقام المرفوعة غير متاحة له. هكذا صُمّمت تيليجرام نفسها: لا يسمح Bot API للبوت بأن يبدأ المراسلة، ولا أحد يستطيع الالتفاف على ذلك.

ومن هنا توزيع بسيط للأدوار في التكامل. يبقى حساب المراسلة الطريقة الوحيدة للوصول إلى شخص لم تراسله بعد. أما البوت فللعمل مع من اشتركوا فيه أصلًا: لا مبرر للحظر في حملة كهذه، ولا دخل لرقم الهاتف فيها إطلاقًا، ولا تحدّ السرعةَ إلا قيودُ المنصة، دون التسخين الحذر الذي يحمي الحساب من الحظر.

الحملات المرتبطة بالأحداث: استدعاء واحد لكل حدث

أنفع ما في الشريحة: الحملة المرتبطة بها لا تنتهي حين تفرغ من الإرسال إلى كل من فيها. تبقى قيد العمل وتنتظر جهات اتصال جديدة: ما إن تضيفها إلى الشريحة حتى يُستأنف الإرسال فورًا.

فالحملة بعد إطلاقها تعمل في جوهرها بمثابة طابور إرسال. ومن هنا المخطط التالي:

1. تنشئ مرة واحدة الشريحة والحملة المرتبطة بها، وتضيف النص، وتطلقها، عبر API أو يدويًا في لوحة التحكم، فلا فرق بعد ذلك.
2. ثم مع كل حدث في نظامك ترسل طلبًا واحدًا: إضافة الرقم إلى الشريحة.

هذا كل شيء. تخرج الرسالة من تلقاء نفسها، بوتيرة آمنة، وبنص مفحوص، ومع مراعاة الحدود. دفع ثمن الطلب، حجز موعدًا، لم يحضر، غاب شهرًا: تحصل على حملاتك الخاصة المرتبطة بالأحداث، وكل ما عليك صيانته استدعاء واحد لكل مناسبة.

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

نص هذه الحملة واحد لجميع المستلمين، مع إدراج الاسم وصيغ بديلة للعبارات. لذلك يُخصَّص لكل مناسبة زوج «شريحة وحملة»: ترحيب، تذكير بالموعد، استعادة عميل. يُنشأ الزوج مرة واحدة، ثم يكتفي بانتظار الأرقام.

ردود العملاء تعود إلى نظامك

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

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

curl https://api.wsender.io/v1/mailing/{MAILING_ID}/recipient/{RECIPIENT_ID}/reply \
  -H "Authorization: key YOUR_TOKEN"

يعيد هذا الطلب الردود على هذه الحملة تحديدًا: تأخذ الخدمة الرسائل التي وصلت بعد الإرسال إلى هذا المستلم، أما المراسلات السابقة فلا تدخل فيها. وبالقاعدة نفسها تُحدَّد حالة «ردّ»، فلا تتعارض الحالة مع المحتوى.

بعدها يذهب الرد إلى نظام CRM لديك: مهمة لمسؤول المبيعات، أو دردشة فريق المبيعات، أو لوحة المؤشرات. وهناك تحفّظان، كي لا تبني على افتراض خاطئ: المراسلة تُسحب من الحساب دوريًا، لذلك يمرّ وقت بين رد الشخص وظهوره في API، وقد تأتي القائمة فارغة إن اكتفى الشخص بوضع تفاعل (reaction) على الرسالة بدل كتابة نص.

إن لم يكن لديك نظام CRM بعد، فالردود نفسها تظهر في تطبيق Dialogs الذي يُفتح من لوحة التحكم: يقرؤها الموظف ويرد منه. والرسائل المرسلة عبر API تحمل هناك توقيع «API»، وعند تمرير المؤشر على التوقيع يظهر المفتاح الذي أُرسلت به.

والأهم ما يخص الباقات. الردود، ومعها محادثات الحساب وجهات اتصاله، تأتي من مزامنة الحساب المتصل، وهي ليست في كل الباقات: الباقة المجانية لا تشملها. يمكنك فيها بناء التكامل واختباره، فالحملات تُنشأ وتُرسل، لكن لن تصلك ردود: لن يصل حدث الرد عبر الويب هوك، وطلب الردود سيعيد الخطأ 403 مع توضيح أن هذه الإمكانية غير متاحة في الباقة. وهذا الخطأ مقصود بدل القائمة الفارغة: لو جاءتك قائمة فارغة لفهمتها على أن «الشخص لم يرد»، ولبحثت عن الخطأ في نظامك.

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

الويب هوك: الخدمة تخبرك بما حدث

لا حاجة إلى سؤال API مرة بعد مرة: «ما الجديد؟». حدّد عنوانك، وستصلك الأحداث من تلقاء نفسها:

curl -X PUT https://api.wsender.io/v1/webhook \
  -H "Authorization: key YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://example.com/wsender","secret":"your-secret"}'

الويب هوك واحد للمشروع، والعنوان على HTTPS حصرًا. استبدل العنوان والسر في المثال بقيمك: يُسمح في السر بالأحرف اللاتينية والأرقام والشرطة والشرطة السفلية. تعيده الخدمة في الترويسة X-WSender-Secret-Token مع كل طلب، فتميّز به أحداثك عن أي طلبات غريبة تصل إلى العنوان نفسه.

تصل أحداث من أربع مجموعات:

• الحساب: اتصل، انفصل، وأثناء الربط: رمز QR جاهز، رمز الربط جاهز، بانتظار رمز التأكيد أو كلمة مرور التحقق بخطوتين، تمّ الربط بنجاح.
• قيود تطبيق المراسلة: قُيّد الحساب، ورُفع القيد. ولعلها الأثمن: عند الحظر يبقى الحساب متصلًا، ومن دون هذا الحدث تتوقف الحملة بصمت.
• الحملة: اجتازت المراجعة، لم تجتزها مع ملاحظات، انطلقت، توقفت مؤقتًا مع ذكر السبب، اكتملت، أُلغيت.
• المستلمون: أُرسلت الرسائل، ردّ الشخص، تعذّر الإرسال، الرقم غير موجود في تطبيق المراسلة.

أحداث المستلمين والرسائل المفردة لا تصل إلا باشتراك صريح. اذكر الأنواع التي تحتاجها في events: القائمة الفارغة لا تفعّلها، كي لا تولّد الحملة الكبيرة سيلًا من الأحداث لا حاجة إليه.

احفظ الحدث الوارد أولًا بشكل موثوق، ثم أعِد الرد 2xx، وبعدها عالجه. إن لم يرد خادمك خلال 10 ثوانٍ أو أعاد خطأً، تكرر الخدمة المحاولة بفواصل من 30 ثانية إلى نصف ساعة. ويُحفظ كل حدث في الطابور يومًا واحدًا على الأكثر من لحظة إنشائه.

قد يصل الحدث نفسه مرتين: تحقّق من id كي لا تنفّذ الإجراء في CRM مرتين.

إن مرّ يوم على أول إخفاق دون تسليم ناجح واحد خلاله، يُعلَّق الويب هوك تلقائيًا. ويصل إلى صاحب المشروع إشعار عبر بوت إشعارات WSENDER في تيليجرام، إن كان قد ربطه. ويمكن التحقق من الحالة بالطلب GET /v1/webhook: في الكائن health تجد الحالة Active أو Suspended، وآخر خطأ، والتواريخ.

بعد إصلاح الخادم المستقبِل لديك، استدعِ POST /v1/webhook/resume بمفتاح يملك صلاحية ضبط الويب هوك:

curl -X POST https://api.wsender.io/v1/webhook/resume \
  -H "Authorization: key YOUR_TOKEN"

ترسل الخدمة إلى عنوانك حدثًا تجريبيًا webhook.test بالسر المعتاد. ولا يُستأنف التسليم إلا إذا ردّ خادمك بـ 2xx. أما POST /v1/webhook/test العادي فيساعد على فحص العنوان، لكنه لا يرفع التعليق.

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

سرعة الإرسال: لماذا لا ترسل API كل شيء دفعة واحدة

هنا تتباعد توقعات المبرمجين عن واقع تطبيقات المراسلة أكثر من أي مكان آخر. تقبل API الطلب فورًا، أما وتيرة الإرسال فتحدّدها الاستراتيجية الآلية: تبدأ بهدوء وتزيد السرعة كلما تراكم لدى الحساب سجل من الإرسال. وإن أبطأت المنصة الحساب، توقف الخدمة الحملة مؤقتًا ثم تواصل بوتيرة أبطأ.

هكذا تحمي الخدمة رقمك: إن أرسلت إلى القاعدة كلها خلال ساعة، فالأرجح أن يقيّد تطبيق المراسلة الحساب. لذلك لا تتيح الخدمة ذلك.

أربعة أمور أخرى يُستحسن مراعاتها قبل التكامل:

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

أين تفيد واجهة API للإرسال الجماعي

• نظام CRM: إشعارات بحالة الصفقة والطلب، وردود العملاء تعود إلى بطاقة العميل.
• المتجر الإلكتروني: تأكيد الطلب، والدفع، والتوصيل.
• الموقع أو صفحة الهبوط: رد فوري على طلب التواصل في تطبيق المراسلة الذي يستخدمه الشخص.
• الحجز الإلكتروني: تذكير بالموعد قبل يوم.
• استعادة العملاء: شريحة «لم يشترِ منذ 3 أشهر» تمتلئ من قاعدتك، والحملة تعالج الطابور بنفسها.

ما التالي

لا رسوم منفصلة مقابل API، فهي تعمل على الباقات العادية، حتى المجانية منها: في الباقة المجانية 15 رسالة يوميًا، وهذا يكفي لبناء التكامل واختباره.

ابدأ بخطوة صغيرة: أنشئ مفتاحًا، ونفّذ طلب قائمة الحسابات، واربط حسابًا واحدًا، وأرسل حملة إلى شريحة فيها رقمك أنت فقط. خلال نصف ساعة تتضح الدورة كاملة. بعدها لا يبقى إلا أن تجهّز زوج «شريحة وحملة» للعمل الفعلي، وتضيف إليه الأرقام من الموضع الذي يقع فيه الحدث في نظامك.

الوصف الكامل لنقاط النهاية في توثيق API، ومواصفات توليد العميل في ملف OpenAPI.