واجهة Chakra Chat API: دليل المطورين الشامل لأتمتة WhatsApp

الخلاصة: تعمل Chakra Chat API فوق WhatsApp Cloud API، وتضيف ما لا يتيحه الوصول المباشر إلى Meta افتراضيًا: مفاتيح API محددة الصلاحيات حسب الدور، وصيغة أسهل لخطافات الويب إلى جانب تمرير بيانات Meta بالكامل، وإدارة مدمجة للعملاء المحتملين والحملات، ونقاط نهاية للمكالمات، وطبقة أوسع للمنصة/CRM (العمليات والمهام والمستخدمون) لبناء تدفقات عمل فعلية، لا مجرد إرسال الرسائل. يغطي هذا الدليل المصادقة (مفاتيح API والأدوار ورموز Bearer)، ومجالات القدرات الستة التي تنظم API، وحدود المعدل (200 استدعاء/دقيقة)، وآلية عمل خطافات الويب الواردة والتحقق من HMAC، ومتى تختار حزمة SDK الرسمية لـ TS/JS بدلًا من استدعاءات HTTP المباشرة، وأنماط التكامل — مزامنة CRM، ومحفزات الأتمتة عبر أدوات مثل n8n، ومنصات التجارة الإلكترونية مثل Shopify، وإرسال الرسائل الجماعية — التي تغطي معظم حالات الاستخدام الواقعية. هذا هو الدليل الذي ينبغي قراءته قبل فتح مستندات API على مستوى نقاط النهاية ؛ فهو يشرح الغرض من النظام وبنيته، لا الاستدعاءات الفردية فحسب.

مقدمة

إذا كنت تقيّم Chakra Chat API، فربما سبق أن اطّلعت مباشرةً على مستندات WhatsApp Cloud API وتتساءل عمّا تضيفه طبقة BSP فعليًا. يجيب هذا الدليل عن ذلك، ثم يستعرض الجوانب العملية — المصادقة، والبنية، وحدود المعدل، وخطافات الويب، ومجموعة تطوير البرمجيات (SDK)، وأنماط التكامل التي ينتهي الأمر بمعظم المطورين إلى بنائها. وللاطّلاع على التفاصيل على مستوى نقاط النهاية (مخططات الطلبات/الاستجابات والمعلمات)، تُعد مستندات Chakra API المرجع الذي يُستحسن إبقاؤه مفتوحًا إلى جانب هذا الدليل.

ما الذي تتيحه Chakra API مقارنةً باستخدام WhatsApp Cloud API مباشرةً؟

تُعد Cloud API من Meta الطبقة الأساسية — فهي التي ترسل رسائل WhatsApp وتتلقاها فعليًا، وتدير القوالب، وتتولى البنية التحتية لأرقام الهواتف. ويُبنى كل مزوّد حلول WhatsApp Business، بما في ذلك Chakra، في نهاية المطاف فوقها. فلماذا لا تتكامل مع Meta مباشرةً؟

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

ما الذي تضيفه Chakra API إلى جانب الوصول المباشر إلى Cloud API؟

• إمكانية تمرير البيانات كما هي، إلى جانب تنسيق أبسط لخطافات الويب. يمكنك تلقي الأحداث مباشرةً بتنسيق Meta الخام، أو بتنسيق أحداث موحّد من Chakra أسهل في التعامل معه — والخيار لك، بحسب حالة الاستخدام.
• مفاتيح API محددة الصلاحيات حسب الدور بدلًا من بيانات اعتماد واحدة تشمل الحساب بأكمله، بحيث لا يحصل كل تكامل (مثل مزامنة Shopify أو أتمتة n8n أو لوحة معلومات داخلية) إلا على الصلاحيات التي يحتاج إليها فعلًا.
• طبقة للعملاء المحتملين والحملات — نقاط نهاية مخصصة لإنشاء سجلات العملاء المحتملين وتحديثها وإدارة حملاتهم، بدلًا من بناء نموذج البيانات هذا بنفسك فوق أحداث المراسلة الخام.
• طبقة للمنصة/CRM — العمليات والمهام والمستخدمون والمهام الخلفية، لتمنحك أساسيات عامة لسير العمل وحفظ السجلات تعمل جنبًا إلى جنب مع نقاط النهاية الخاصة بـ WhatsApp، وتفيد عندما يكون تكامل WhatsApp جزءًا من نظام تشغيلي أوسع.
• نقاط نهاية API للاتصال لإمكانات الاتصال الصوتي في WhatsApp — الإعدادات والأذونات وإدارة المكالمات — بوصفها مجالًا مدعومًا أصليًا، لا ميزة أُضيفت بشكل منفصل.
• صندوق وارد مشترك وأدوات لغير المطورين ضمن الحساب نفسه، بحيث لا تكون API الطريقة الوحيدة للوصول إلى النظام — إذ يعمل فريقا الدعم والتسويق على المنصة نفسها التي تستند إليها تكاملاتك.

متى قد يظل التكامل المباشر مع Meta خيارًا مناسبًا؟ إذا كنت تبني بنية تحتية واسعة النطاق جدًا مع فريق متخصص بالمنصة، أو كنت تحتاج إلى وظائف Cloud API فور إطلاق Meta لها، قبل أن تلحق بها أي طبقة BSP. أما بالنسبة إلى معظم فرق المنتجات والنمو — أي الفرق التي تبني الأتمتة أو مزامنة CRM أو تدفقات موجهة للعملاء من دون الرغبة في تحمّل مسؤولية مجموعة البنية التحتية الكاملة للمراسلة — فإن استخدام API من مزوّد BSP مثل Chakra هو المسار الأسرع والأقل عبئًا في الصيانة.

المصادقة: مفاتيح API والأدوار ورموز Bearer

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

إنشاء مفتاح API:

1. انتقل إلى قسم مفاتيح API في حسابك على Chakra Chat.
2. امنحه اسمًا معبّرًا — فغالبًا ما سينتهي بك الأمر إلى امتلاك عدة مفاتيح بمرور الوقت، لذا فإن تسميتها بحسب حالة الاستخدام ("n8n-support-bot" أو "shopify-order-sync") ستجعل إدارتها أسهل بكثير لاحقًا مقارنةً بالأسماء العامة.
3. أضف وصفًا اختياريًا لمزيد من السياق.
4. حدّد دور الوصول. يرث المفتاح الصلاحيات المحددة للدور الذي تعيّنه له، ولا شيء أكثر.

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

Authorization: Bearer {your_access_token}

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

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

بنية API: مجالات الإمكانات الستة

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

1. المراسلة — إرسال رسائل WhatsApp الفعلية واستقبالها. ويشمل ذلك رسائل الجلسات (الرسائل الحرة ضمن نافذة الـ24 ساعة)، ورفع الوسائط واسترجاعها، وإدارة مفاتيح WhatsApp Flows، وإدارة المجموعات (إنشاؤها وعرضها وإدارة المشاركين وطلبات الانضمام). ويتوفر هنا كل من مسار تمرير البيانات بتنسيق Meta ومسارات رسائل Chakra الأصلية.

2. القوالب — إنشاء قوالب رسائل WhatsApp وعرضها وتحديثها، إلى جانب نقاط نهاية مخصصة لإرسال رسائل القوالب إما إلى رقم هاتف محدد أو ضمن سياق عملية (راجع المنصة أدناه). وقد فُصلت عمدًا نقاط نهاية إرسال القوالب عن نقاط نهاية إدارتها، لأن دورة إنشاء القالب وإدارته (الخاضعة لعملية الموافقة لدى Meta) تختلف عن إرسال قالب معتمد مسبقًا.

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

4. الحملات — إضافة أرقام الهواتف إلى حملات العملاء المحتملين أو إزالتها منها، وهو أساس بناء تسلسلات تواصل صادرة منظمة (مثل تدفقات المتابعة وشرائح البث)، بدلًا من إرسال رسائل لمرة واحدة.

5. الاتصال — واجهة WhatsApp Calling API: جلب إعدادات الاتصال لرقم هاتف وضبطها، والتحقق من حالة أذونات الاتصال (أي ما إذا كان جهة اتصال معينة قد منحت النشاط التجاري إذنًا لبدء المكالمات)، وإدارة المكالمات النشطة.

6. المنصة/CRM — طبقة سير العمل العامة: العمليات (إنشاء وتحديث وعرض وإجراء عمليات جماعية وحذف — وهي في الأساس سجلات منظمة قابلة للتهيئة)، والمهام، والمستخدمون، والصور، والمهام الخلفية. وهذا الجزء من API لا يرتبط بـ WhatsApp إطلاقًا — إنه مجموعة خفيفة من أساسيات CRM وسير العمل تعمل جنبًا إلى جنب مع إمكانات المراسلة، وتفيد عندما تريد أن تعيش بيانات تكامل WhatsApp وبياناتك التشغيلية الأوسع في النظام نفسه، بدلًا من تجميعها معًا عبر أدوات منفصلة.

إلى جانب هذه المجالات الستة، يجدر التعرّف على مجالين داعمين: الدردشة ورسائل الدردشة (لعرض المحادثات وسجل الرسائل المرتبط برقم هاتف أو محادثة — وهو مفيد لإنشاء عروض مخصصة لصندوق الوارد أو جلب السياق إلى نظام آخر)، و وصول الشركاء (إنشاء Connect Token وإدارة إعدادات إضافة WhatsApp وWABA — وهذا مهم إذا كنت تبني على Chakra بصفتك شريكًا يقدّم خدمة مضمّنة، لا بصفتك تكاملًا لحساب واحد).

حدود معدّل الطلبات وما تعنيه عمليًا

تفرض Chakra حدًا أقصى يبلغ 200 استدعاء API في الدقيقة. هذا هو الرقم الذي ينبغي أن تصمّم نظامك على أساسه، لا أن تكتفي بمعرفته.

ما الذي يعنيه ذلك عمليًا:

• تتطلب العمليات المجمّعة تقسيم العمل إلى دفعات، لا تنفيذه بالقوة. إذا كنت تزامن قائمة كبيرة من العملاء المحتملين أو ترسل رسالة جماعية إلى آلاف المستلمين، فقسّم العمل إلى دفعات مع ضبط وتيرة التنفيذ، بدلًا من إرسال كل الطلبات بأقصى سرعة تسمح بها حلقة التعليمات البرمجية.
• أضف آلية للتراجع التدريجي. ينبغي لأي تكامل يُجري طلبات متكررة التعامل مع استجابات تجاوز حدود المعدّل بسلاسة — أعد المحاولة مع زيادة فترات الانتظار تدريجيًا، بدلًا من إيقاف العملية بأكملها أو إغراق API بالطلبات فور تلقي استجابة تجاوز الحد.
• تظل البنى القائمة على Webhook ضمن الحد تلقائيًا في معظم حالات الاستخدام ، لأنها تستجيب للأحداث الواردة بدلًا من الاستقصاء المتكرر — وهذا سبب إضافي للاعتماد على Webhook (الذي سنتناوله لاحقًا) بدلًا من أنماط الاستقصاء في كل ما يتطلب قراءة مكثفة، مثل التحقق من الرسائل الجديدة أو تحديثات الحالة.
• ينبغي تشغيل مهام البث أو المزامنة ذات الحجم الكبير كمهام في الخلفية، لا ضمن طلب يواجهه المستخدم — فواجهات Background Job في طبقة Platform موجودة جزئيًا لهذا السبب، إذ تتيح لك تتبّع عمليات الدُفعات طويلة الأمد من دون التقيد الفوري بسقف 200 طلب في الدقيقة.

Webhooks: الأحداث الواردة وما يمكنك فعله بها

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

هناك نوعان مختلفان من Webhook، واختيار النوع المناسب مهم:

Webhook للأحداث المنقولة مباشرةً — يرسل تنسيق الأحداث الخام من Meta مباشرةً إلى نقطة النهاية الخاصة بك، دون تعديل. ويشمل ذلك الرسائل الواردة، وأحداث الحالة، وإشعارات تحديث القوالب، وتحديثات مستوى الحساب. اضبطه من علامة التبويب "المزيد" في صفحة إعداد WhatsApp، ضمن حقل عنوان URL لـ Webhook المنقول مباشرةً. وبما أن التنسيق يطابق وثائق Meta نفسها تمامًا، فهو الخيار المناسب إذا كنت على دراية مسبقة بحمولات Cloud API أو تحتاج إلى الوصول إلى أنواع أحداث لا يغطيها التنسيق الموحّد.

Webhook أحداث Chakra — تنسيق أوضح وموحّد لمجموعة مختارة من أنواع الأحداث. يمكنك ضبطه من صفحة إعداد WhatsApp نفسها عبر تفعيل "Chakra Webhooks" واختيار أنواع الأحداث التي تريد تلقيها. تصل الأحداث بمفتاحين ثابتين: event (أحد الأنواع التالية: message, status, message_echo، أو smb_message_echo) و payload (بيانات الرسالة أو حالة التسليم المقابلة). وهو الخيار الافتراضي الأفضل لمعظم عمليات التكامل، إذ لا تحتاج إلى تحليل بنية الأحداث المتداخلة الكاملة من Meta في حالات الاستخدام البسيطة، مثل «أبلغني عندما يردّ أحد العملاء».

يعطيك مثال على حدث رسالة نصية واردة (بالتنسيق المنقول مباشرةً) فكرة عن البنية التي ستتعامل معها:

{  "object": "whatsapp_business_account",  "entry": [{    "id": "83784929738012",    "changes": [{      "value": {        "messaging_product": "whatsapp",        "metadata": { "display_phone_number": "917259775805", "phone_number_id": "694794789348887" },        "contacts": [{ "profile": { "name": "John" }, "wa_id": "919911223344" }],        "messages": [{          "from": "919911223344",          "id": "wamid.xxxx",          "timestamp": "1756322278",          "text": { "body": "Hi, can you please help me out with an issue" },          "type": "text"        }]      },      "field": "messages"    }]  }]}

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

1. عيّن سر HMAC ضمن الإدارة → الفريق → الأسرار في حساب Chakra. بعد تعيينه، يتضمن كل حدث من Webhook ترويسة X-Chakra-Signature-256 .
2. من جهتك، احسب تجزئة HMAC-SHA256 لـ سلسلة نص الطلب الخام (وليس لكائن JSON بعد تحليله وإعادة تسلسله — فكثير من أطر عمل HTTP تحوّل نص الطلب، ما يؤدي إلى فشل المقارنة) باستخدام السر كمفتاح.
3. قارن التجزئة التي حسبتها بالقيمة الموجودة في X-Chakra-Signature-256 (ملاحظة: لا تحتوي قيمة الترويسة على البادئة sha256= ، بخلاف ما تعتمده بعض الخدمات الأخرى). ويؤكد التطابق صحة الحمولة وعدم العبث بها.

💡تجاوز هذه الخطوة يعني أن أي شخص يكتشف عنوان URL الخاص بـ Webhook يمكنه إرسال أحداث مزيفة إليه — لذا يجدر اعتبارها خطوة إلزامية لأي تكامل في بيئة الإنتاج، لا إجراءً أمنيًا اختياريًا.

SDK — متى تستخدمه ومتى تلجأ إلى استدعاءات API مباشرةً

تنشر Chakra حزمة SDK رسمية لـ TypeScript/JavaScript، @chakrahq/chakra-chat-sdk، يمكن استخدامها في بيئات JavaScript على جانب الخادم والعميل.

npm i @chakrahq/chakra-chat-sdk

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

متى يكون SDK الخيار الأفضل:

• إذا كنت تطوّر ضمن بيئة Node.js أو JavaScript/TypeScript وتريد أنواعًا محددة للطلبات والاستجابات، بدلًا من كتابة استدعاءات HTTP وتحليل JSON الخام بنفسك.
• إذا كنت تستدعي نقاط نهاية متعددة ضمن الخدمة نفسها وتريد عميلًا واحدًا مهيّأً بدلًا من تكرار منطق ترويسة المصادقة في كل مكان.
• إذا أردت تسريع التطوير الأولي ولا تمانع وتيرة إصدار SDK فيما يتعلق بنقاط النهاية الأحدث.

متى تكون استدعاءات HTTP المباشرة أنسب:

• إذا كنت تنفّذ التكامل من بيئة غير JavaScript (مثل Python أو Ruby أو Go، أو أداة منخفضة البرمجة مثل عقدة HTTP Request في n8n) — يمكن استخدام API بالكامل عبر طلبات HTTP عادية، وهذا في الواقع النمط الأكثر شيوعًا لعمليات التكامل مع منصات الأتمتة، إذ تعمل أدوات مثل n8n مباشرةً مع عقد HTTP بدلًا من استيراد حزمة npm.
• إذا كنت تحتاج إلى نقطة نهاية متاحة عبر API المباشر، لكن لم تُضمّن بعد في إصدار SDK الحالي.
• إذا كنت تنفّذ تكاملًا بسيطًا لمرة واحدة، ولا يستحق الأمر إضافة اعتماد كامل على SDK مقابل عدد قليل من الاستدعاءات.

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

أنماط التكامل الشائعة

مزامنة CRM. استخدم نقاط نهاية العملاء المحتملين (Create a lead, Update Lead By Phone Number) لمزامنة سجل العميل أو العميل المحتمل مع تطوّر محادثات WhatsApp، واربط ذلك بنقاط نهاية Process/Task في طبقة Platform إذا أردت تتبّع السجلات المنظمة وحالة سير العمل في النظام نفسه، بدلًا من تبادل البيانات ذهابًا وإيابًا مع CRM خارجي عند كل تحديث.

مشغّلات الأتمتة عبر n8n. نمط شائع: اضبط Webhook المنقول مباشرةً ليتصل بعقدة مشغّل Webhook في n8n، ثم صفِّ أحداث الرسائل، وأرسل محتوى الرسالة إلى عقدة AI Agent (أو إلى أي منطق معالجة)، وبعدها أرسل الرد عبر عقدة HTTP Request التي تستدعي نقطة نهاية الرسائل مباشرةً:

POST https://api.chakrahq.com/v1/ext/plugin/whatsapp/{pluginId}/api/v22.0/{whatsappPhoneNumberId}/messagesAuthorization: Bearer {chakraAccessToken}Content-Type: application/json

تتوفر قيمتا pluginId و whatsappPhoneNumberId كلتاهما في صفحة إعداد WhatsApp ضمن حساب Chakra — ويمكن الوصول إلى معرّف الإضافة من قائمة النقاط الثلاث بجوار «حفظ»، وإلى معرّف Meta لرقم الهاتف من رمز الترس بجوار قائمة أرقام الهواتف. ويمكن تعميم هذا النمط — استقبال Webhook، والمعالجة، ثم إجراء استدعاء HTTP — ليتجاوز n8n إلى أي أداة لأتمتة سير العمل تدعم مشغّلات Webhook وعقد طلبات HTTP.

أتمتة دورة حياة طلبات التجارة الإلكترونية (تكامل من نوع Shopify). بدلًا من إنشاء ذلك انطلاقًا من webhooks خام، تتصل المنصات مثل Shopify عادةً عبر طبقة مزامنة لا تتطلب كتابة أي تعليمات برمجية، وتربط أحداث دورة حياة الطلب (إنشاؤه، وتجهيزه، وشحنه، وتسليمه) بإرسال الرسائل النموذجية تلقائيًا، إلى جانب أحداث التخلي عن إتمام الشراء التي تغذي تسلسلات النماذج لاستعادة السلات. وبالنسبة إلى منصات التجارة الإلكترونية المخصصة أو غير التابعة لـ Shopify التي لا تتضمن تكاملًا أصليًا، يمكن بناء النمط نفسه مباشرةً على API: إذ يؤدي webhook لحالة الطلب من منصتك إلى تشغيل معالج من جهة الخادم يستدعي نقطة نهاية إرسال النموذج مع ملء المتغيرات المناسبة من بيانات الطلب.

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

الخطوات التالية

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

• مفاتيح API — إنشاء المفاتيح وتحديد نطاقها
• Webhook للأحداث الواردة — مرجع كامل لـ webhook والتحقق من HMAC
• حدود معدل API
• حزمة تطوير Chakra Chat
• كيفية تحديد pluginId وwhatsappPhoneNumberId — وهما ضروريان لمعظم عمليات التكامل المباشرة عبر HTTP

للاطلاع على شرح عملي لبناء أتمتة محددة، يستند كل من دليل تكامل وكيل الذكاء الاصطناعي في n8n و دليل تكامل Shopify مباشرةً إلى المفاهيم التي تناولها هذا الدليل — ابدأ بهذا الدليل لفهم بنية النظام، ثم استعِن بهذين الدليلين لبناء عملي خطوة بخطوة.