إصدار تجريبي (Beta). واجهة برمجة تطبيقات الأتمتة قيد الإصدار التجريبي ونحن نجمع الملاحظات بنشاط. قد تتغير نقاط النهاية والحمولات والحدود مع تطويرنا لها. يُرجى إرسال الملاحظات وتقارير الأخطاء إلى الدعم لكي نتمكّن من ترتيب أولويات التحسينات الصحيحة.
تعني
sent أن Meta قبلت الرسالة، وليس أن المستلم قد استلمها. على Instagram، يُحدَّد التسليم في نهاية المطاف بإعداد Message requests الخاص بالمستلم: إذا لم يكن يسمح بطلبات الرسائل من الجميع، تُعيد Meta استجابة نجاح وتُسقط الرسالة بصمت، وهذا غير مرئي على أي مستوى في واجهة برمجة التطبيقات. حتى الرسالة الخاصة المُشغَّلة بتعليق التي تصل بنجاح تظهر لدى المستلم كـ طلب رسالة يجب على المستلم قبوله (إلا إذا كانت هناك محادثة قائمة بالفعل بين الحسابين). راجع رسالة أتمتة أُرسلت لكنها لم تُسلَّم للاطلاع على الشرح الكامل.كيف يعمل
1
أنشئ أتمتة
POST /automations مع المشغّلات والإجراءات التي تريدها. تنشط الأتمتة على الفور.2
يتفاعل مستخدم نهائي
يُعلّق شخص ما على منشورك أو يردّ على ستوري أو يُرسل رسالة خاصة أو يتفاعل مع رسالة خاصة. ترسل Meta الـ Webhook إلى Ayrshare.
3
يطابق Ayrshare ويُرسل
يُطبَّق تأخير عشوائي من 20 إلى 60 ثانية على التفاعل للبقاء ضمن قواعد Instagram لمكافحة الرسائل غير المرغوبة. بعد ذلك يبحث المحرّك عن كل قاعدة تُطابق الحدث، ويتحقق من إزالة التكرار لكل إجراء وحدّك اليومي للرسائل الخاصة، ثم يُنفّذ كل إجراء.
4
افحص ما تم إطلاقه
يُعيد
GET /automations/:id/activity سجل التدقيق — كل محاولة إرسال ونتائج كل إجراء وأي أخطاء.المشغّلات
يمكنك ربط ما يصل إلى 50 مشغّلًا بأتمتة واحدة. كل مشغّل عبارة عن اتحاد مميّز على الحقلtype؛ توجد الحقول الخاصة بالنوع على نفس المستوى. يوضّح عمود المنصات أين يتوفر كل مشغّل؛ راجع صفحات Facebook لمعرفة ما يحتاجه Facebook.
يكون تطابق الكلمات المفتاحية غير حساس لحالة الأحرف ومطابقة كلمة كاملة. يستوفي الحدث مشغّلًا مُصفّى بالكلمات المفتاحية إذا كان يحتوي على أي كلمة من الكلمات المُهيَّأة.
القواعد الدائمة باستخدام "all"
عيّن postId (أو storyId) إلى السلسلة الحرفية بأحرف صغيرة "all" للإطلاق على كل منشور أو Reel أو ستوري على الحساب المتصل بدلًا من قطعة محتوى واحدة محددة. هذا ما تريده لقاعدة يجب أن تستمر في العمل مع نشر محتوى جديد، دون استدعاء لواجهة برمجة التطبيقات لكل منشور:
"all". تُرفض صيغة مغايرة مثل "ALL" أو " all" بخطأ تحقّق بدلًا من حفظها كمعرّف منشور لن يتطابق أبدًا.
لا يتوسّع "all" أبدًا خارج الحساب المتصل — لا يمكن لقاعدة على ملف شخصي واحد أن تُطلق على محتوى ملف شخصي آخر. يسري حدّك اليومي للرسائل الخاصة وقواعد الإرسال المرتبطة بالتفاعل تمامًا كما تسري على قاعدة منشور واحد.
في مشغّلات الستوري، يسلك حذف
storyId السلوك نفسه الذي تسلكه "all". فضّل "all" — فهي تُعبّر عن النية صراحةً، وسيُوقف العمل بالحذف في إصدار مستقبلي مع إشعار مسبق في التغييرات القادمة في واجهة برمجة التطبيقات.صفحات Facebook
عيّنplatform على facebook لتشغيل أتمتة على صفحة Facebook المرتبطة بالملف الشخصي. تُرسَل الرسائل الخاصة من الصفحة عبر Messenger.
- المشغّلات:
dm_keywordوdm_reaction. مشغّلات التعليقات والستوري مقتصرة على Instagram حاليًا، وتُرفض أتمتة Facebook التي تستخدم أحدها مع خطأ تحقق. - المراسلة: يحتاج الملف الشخصي إلى تفعيل Messaging لـ Facebook، تمامًا كما هو الحال عند إرسال رسالة خاصة على Facebook باستخدام Messages API.
- المستلم:
{{recipient_id}}هو المعرّف الخاص بالصفحة للمستخدم (PSID). يكون{{recipient_username}}فارغًا، لأن Webhooks الخاصة بـ Messenger لا تتضمن اسم مستخدم.
الإجراءات
يمكنك ربط ما يصل إلى 50 إجراءً بأتمتة واحدة. تُنفَّذ بالتتابع؛ ويُسجَّل كل نتيجة في صف النشاط.نافذة إزالة التكرار لكل إجراء
يقبل كل إجراء — بغض النظر عن نوعه — حقلًا اختياريًا إضافيًا على المستوى الأعلى باسمdedupWindowMinutes يتجاوز نافذة 7 أيام الافتراضية لإزالة التكرار لكل مستلم لذلك الإجراء فقط.
- عيّنه إلى
0لتعطيل إزالة التكرار كليًا لذلك الإجراء (نموذجي لـfire_webhook/send_emailحيث يتوقّع المستقبِل كل حدث). - محدود بحد أقصى
525600(سنة واحدة).
إجراء مع تجاوز إزالة تكرار لمدة 24 ساعة
محتوى الرسالة الديناميكي
افتراضيًا، يُرسلsend_dm نفس message إلى كل من يُطلق القاعدة. العلامات النائبة مثل {{recipient_username}} هي الجزء الوحيد الذي يتغيّر من شخص لآخر. عيّن messageUrl على الإجراء، وسيتولى خادمك كتابة الرسالة الخاصة لكل شخص بدلًا من ذلك: في كل مرة تتطابق فيها القاعدة، نسأل نقطة النهاية لديك عمّا يجب قوله، ثم نُرسل إجابتها كرسالة خاصة.
مثال. تردّ قاعدتك على كل من يُعلّق بكلمة “LINK” على منشور، ويشير messageUrl إلى خادمك. عندما تُعلّق Ava بـ “LINK please!”:
- نُرسل
POSTبالتفاصيل إلىmessageUrlالخاص بك: من علّق ("recipientUsername": "ava")، وماذا كتب، وعلى أي منشور. - يكتب خادمك ردًّا لـ Ava، على سبيل المثال مع رابط تتبّع مُنشأ خصيصًا لها، ويُجيب بـ
{ "message": "Hi ava, here's your link: https://example.com/r/12345" }. - نُرسل ذلك النص إلى Ava كرسالة خاصة، تمامًا كما كتبته.
timeoutMs، أو أعاد خطأ، أو أعاد شيئًا لا يمكننا استخدامه، نُرسل إلى Ava الرسالة message العادية للإجراء بدلًا من ذلك، بحيث تتلقى ردًّا على أي حال.
أضِفه إلى إجراء send_dm على هذا النحو:
send_dm with messageUrl
messageUrl هو المكان الذي نطلب منه النص. لا يزال message مطلوبًا وهو البديل الاحتياطي: لا يُرسل أبدًا إلى خادمك، ونُرسله كرسالة خاصة بدلًا من ذلك كلما لم يُجب خادمك في الوقت المحدد، أو أعاد خطأ، أو أعاد شيئًا لا يمكننا استخدامه (راجع التحذير أدناه). timeoutMs اختياري (الافتراضي 3000، والحد الأقصى 5000).
ما نُرسله إلى نقطة النهاية لديك. طلب POST بجسم JSON التالي:
Callback request body
إذا كنت قد سجّلت سرّ Webhook، فإن الجسم يُوقَّع بالسرّ نفسه المستخدم في Webhooks الخاصة بـ
automations، وبالطريقة نفسها: X-Authorization-Content-SHA256 هو HMAC-SHA256 للجسم الخام، ويحمل X-Authorization-Timestamp قيمة timeStamp الخاصة بالجسم. تعمل شيفرة التحقق التي تستخدمها بالفعل لـ Webhooks الخاصة بنا دون تغيير. إذا كان هناك سرّ مُسجَّل لكن تعذّرت علينا قراءته في تلك اللحظة، فإننا لا نُرسل الاستدعاء دون توقيع؛ بل نُرسل قالب message الخاص بك بدلًا من ذلك.
إلى أين يمكن أن يشير. يجب أن يكون messageUrl عنوان HTTPS عامًا. يُرفض أي عنوان URL يُحلّ إلى عنوان خاص، أو عنوان استرجاع (loopback)، أو عنوان link-local، أو عنوان بيانات وصفية سحابية، ولا تُتبع عمليات إعادة التوجيه — فالإجابة 3xx تُحتسب فشلًا. وفي كلتا الحالتين يُرسل القالب بدلًا من ذلك.
ما تُعيده نقطة النهاية لديك. أعِد 200 مع جسم JSON، بحجم 16 KB كحد أقصى، يحتوي على سلسلة message يتراوح طولها بين 1 و1000 حرف:
{{placeholder}}، لذا فإن {{ الحرفية في نصك المُنشأ تصل إلى المستلم كما كُتبت.
القيمة الافتراضية لـ timeoutMs هي 3000. والحد الأقصى هو 5000: تُرفض القيمة الأكبر بخطأ تحقّق عند إنشاء الأتمتة أو تحديثها. وهي تغطي عملية التبادل بأكملها، بما في ذلك قراءة جسم استجابتك. خطّط لذلك: تُرسل الرسالة الخاصة بعد أن تُجيب نقطة النهاية لديك، لذا فإن نقطة النهاية البطيئة تؤخّر الرسالة.
تحقّق من المسار الذي سلكه الإطلاق عبر GET /automations/:id/activity. يحمل إدخال send_dm في actionResults[] الحقل messageSource بمجرد تحديد نص الرسالة الخاصة، بما في ذلك عندما يفشل الإرسال بعد ذلك. ويغيب عندما يتوقف الإجراء قبل ذلك، على سبيل المثال رسالة خاصة skipped إلى حسابك الخاص أو إجراء deduplicated:
يوضّح
messageSource النص الذي بُنيت منه الرسالة الخاصة، لا ما إذا كانت قد سُلّمت. اقرأ status الخاصة بالإدخال لمعرفة ذلك.
لا يؤدي الرجوع إلى البديل وحده إلى فشل الإجراء: عندما تُسلَّم الرسالة الخاصة القالبية، يكون الإدخال sent، مع سبب عدم استخدام الاستدعاء في errorDetails. وإذا فشلت الرسالة الخاصة القالبية أيضًا، يكون الإدخال failed ويُقدّم errorDetails خطأ الإرسال متبوعًا بسبب الاستدعاء. راقب ذلك: فالاستدعاء الذي يفشل في كل إطلاق يبدو خلاف ذلك تمامًا مثل استدعاء يعمل.
احرص على أن تكون message قابلة للإرسال بمفردها. إذا عُولجت إلى قيمة فارغة لمستلم ما، على سبيل المثال {{recipient_username}} وحدها في مشغّل رسائل خاصة لا يحمل اسم مستخدم، ولم يُستخدم نص الاستدعاء، فلن تُرسل أي رسالة خاصة ويكون الإجراء failed مع السبب في errorDetails.
أحداث Webhook
يُسلَّم حدثان إلى إجراء webhook باسمautomations الذي تُسجّله عبر POST /hook/webhook. يحمل كلاهما حقل type — فرِّق بناءً عليه قبل قراءة أي شيء آخر.
يكون
automation.completed معطَّلًا افتراضيًا. فعِّله لأتمتة ما بضبط "sendCompletedEvent": true على إجرائها fire_webhook. ويبقى معطَّلًا خلاف ذلك، بحيث يستمر المستقبِل المبني على حمولة واحدة لكل إطلاق في تلقي حمولة واحدة بالضبط. automation.triggered ليس سجلًا لكل تطابق: فهو يُرسل فقط عندما يُنفَّذ fire_webhook نفسه، لذا فإن التطابق الذي ينتهي بـ rate_limited أو deduplicated يُنتج automation.completed وحده. ولا يُرسل أي من الحدثين لأتمتة أُلغي تنشيطها أو حُذفت قبل تنفيذ الإرسال.automation.triggered
activityId هو الصف الذي يُعيده GET /automations/:id/activity، لذا يمكنك ربط الاثنين بدقة بدلًا من المطابقة على recipientId + triggerId + keyword — وهو أمر ملتبس عندما يُعلّق عدة أشخاص بالكلمة المفتاحية نفسها في الوقت ذاته. actionId هو إجراء fire_webhook الذي أرسل الحدث، ويطابق actionResults[].actionId؛ وهو ما يميّز بين إجرائي fire_webhook على القاعدة نفسها.
الحقول التي لا يملؤها المشغّل تكون بقيمة null بدلًا من حذفها، بحيث يبقى الشكل ثابتًا. تكون recipientUsername بقيمة null لـ dm_keyword وdm_reaction وstory_reply، لأن حمولة Meta لا تتضمن اسم مستخدم. يُضبط commentId فقط لـ comment_keyword وstory_comment، وpostId فقط لـ comment_keyword، وstoryId فقط لمشغّلات الستوري. لا يوجد keyword لـ story_reply. بالنسبة إلى dm_keyword، تكون commentText هي نص الرسالة الخاصة؛ وبالنسبة إلى dm_reaction، تكون commentText وkeyword كلتاهما الرمز التعبيري للتفاعل.
automation.completed
يُرسل فقط عندما تُفعّله الأتمتة في إجرائها fire_webhook:
fire_webhook action with the outcome event on
status وكل actionResults[].status نفس قيم سجل النشاط — sent وfailed وrate_limited وdeduplicated وskipped وauth_error — لذا في الحالة العادية تعرف كيف انتهى الإرسال دون استطلاع. غير أن تسليم هذا الحدث يتم على أساس أفضل جهد ممكن: إذا توقفت العملية بين تسجيل النتيجة ووضع الحدث في قائمة الانتظار، فلن يُرسل. سجل النشاط هو المرجع الموثوق، لذا إذا كنت بحاجة إلى كل نتيجة، فطابق مقابل GET /automations/:id/activity لأي activityId لم يُبلّغ عن نتيجة. تحمل نتيجة send_dm أيضًا الحقل messageSource، كما في سجل النشاط: template أو callback أو fallback، بحيث يمكنك رصد messageUrl يستمر في الرجوع إلى البديل دون استطلاع. طابق النتائج مع إجراءاتك المُهيَّأة حسب actionId، لا حسب الموضع — فإجراءان من النوع نفسه لا يمكن تمييزهما إلا بهذه الطريقة. تكون actionResults فارغة في ثلاث حالات، ولكل منها السبب في errorDetails على المستوى الأعلى حيثما وُجد: rate_limited (تم بلوغ حدّك اليومي)، وdeduplicated (كان كل إجراء داخل نافذة إزالة التكرار الخاصة به)، وfailed بعد إعادة محاولة الإرسال الحد الأقصى من المرات دون اكتماله. في الحالة الأخيرة قد تكون بعض الإجراءات قد نُفّذت بالفعل، لذا قد تكون رسالة خاصة قد خرجت وقد يكون automation.triggered قد أُرسل بالفعل.
يتم تسليم Webhook بمبدأ مرة واحدة على الأقل، لذا قد يصل الحدث نفسه مرتين أحيانًا، ويمكن للإرسال الذي تُعاد محاولته أن يُرسل automation.triggered مجددًا بـ hookId جديد. لا تُزل التكرار أبدًا بناءً على hookId. اجعل مفتاح كل نوع حدث منفصلًا، بحيث لا تؤدي معالجة أحدهما مطلقًا إلى كبح الآخر: automation.completed على activityId (لكل نشاط نتيجة واحدة)، وautomation.triggered على activityId بالإضافة إلى actionId (واحد لكل إجراء fire_webhook). يُسلَّم الحدثان بشكل مستقل، لذا قد يصل automation.completed أحيانًا قبل automation.triggered.
إذا لم يكن هناك webhook مُسجَّل
يُرسلfire_webhook إلى إجراء automations المُسجَّل على الملف الشخصي، مع الرجوع إلى Primary Profile الخاص بك. لا يوجد رجوع إلى إجراء آخر مثل messages. إذا لم يوجد أي من التسجيلين، فلا يُسقط automation.triggered بصمت: يُسجَّل الإجراء في صف النشاط بوصفه failed، مع السبب في actionResults[].errorDetails. (لا وجهة لـ automation.completed أيضًا، ولا يُسجَّل.) تتبع الحالة الإجمالية للإرسال بعد ذلك الأسبقية المعتادة: auth_error إذا واجه أي إجراء خطأ مصادقة، وإلا sent إذا قُبل أي إجراء، وإلا failed. لذا لا يُحتسب الـ webhook المفقود ضمن إحصاءات فشل الأتمتة إلا عندما لا يُرسل أي شيء آخر في القاعدة؛ وعندما يُرسل إجراء آخر بالفعل (ولم يواجه أي منها خطأ مصادقة)، ينتهي الإرسال بـ sent ويظهر الـ webhook الفاشل في actionResults[] فقط.
تعني نتيجة sent لـ fire_webhook أن الحدث وُضع في قائمة الانتظار للتسليم إلى عنوان URL الخاص بك، وليس أن نقطة النهاية لديك قبلته. تُعاد محاولة التسليم بعد ذلك وفق جدولها الخاص.
متغيرات القالب
تدعمsend_dm.message وsend_email.subject وsend_email.message استبدال {{placeholder}}. تُرفض العلامات النائبة غير المعروفة عند الإنشاء/التحديث (كخطأ تحقّق 473) بحيث لا يُسرّب خطأ إملائي سلسلة {{foo}} الحرفية إلى رسالة موجّهة للعميل.
لا يوجد
sender_email / recipient_email. لم يتم كشفهما عمدًا — بريدك الإلكتروني للفوترة لا مكان مشروع له في رسالة خاصة إلى غريب، ولا توفّر Meta بريد المستلم الإلكتروني في أي Webhook خاص بـ IG. تجنُّب العلامات النائبة يمنع الكشف العرضي.حدود المعدل والقيود
يُحتسب الحد الأقصى للأتمتة النشطة لكل ملف تعريف مستخدم، وليس لكل حساب أصلي. يحصل كل ملف شخصي ضمن حسابك على 10 لـ Launch/Business أو 50 لـ Enterprise الخاصة به، لذا يمكن لحساب به عدة ملفات شخصية تشغيل هذا العدد من الأتمتة على كل منها. يُحصي الأتمتة النشطة ويُطبَّق على كل من
POST (إنشاء) وPUT لإعادة التنشيط (active: false → true)، ويعرض كل منهما رمز الخطأ 470. تحتاج إلى حد أعلى لكل ملف شخصي؟ اتصل بالدعم لرفعه لحسابك.
يُطبَّق الحد اليومي للرسائل الخاصة لكل حساب Ayrshare أصلي، ويُتشارك عبر جميع ملفاتك الشخصية، مع حد فرعي لكل ملف شخصي بحيث لا يستنزف ملف شخصي واحد مشغول حصة الحساب بأكمله. عند بلوغ حد الرسائل الخاصة، يُسجل صف النشاط الحالة rate_limited ولا تُرسَل الرسالة الخاصة.
يُطبَّق حد محادثات المراسلة أيضًا. يتطلب send_dm إضافة Messaging على الملف الشخصي، وتُحتسب كل رسالة خاصة يرسلها ضمن حد المحادثة الشهري لذلك الملف الشخصي، تمامًا كرسالة خاصة ترسلها بنفسك. عند بلوغ الحد، لا يُرسَل send_dm إلى مستلم جديد ويُسجل صف النشاط الحالة failed، مع رسالة الحد في actionResults[].errorDetails. الرسائل الخاصة التي يُطلقها تعليق (comment_keyword وstory_comment) هي الاستثناء: فهي لا تزال تُرسَل عند بلوغ الحد، ولا تزال تُحتسب.
القيود الهيكلية على أتمتة واحدة: من 1 إلى 50 مشغّلًا، من 1 إلى 50 إجراءً.
يُحدد Instagram نفسه الرسائل الخاصة بنحو 200/ساعة لكل حساب. يُوزّع المحرك الإرسال بتأخير عشوائي من 20 إلى 60 ثانية للبقاء بأمان تحت هذا الحد.
حالات النشاط
يحمل صف فيGET /automations/:id/activity حالة status على المستوى الأعلى بالإضافة إلى status لكل إجراء داخل actionResults[]:
pending وin_flight مؤقتتان؛ وكل الحالات الأخرى نهائية.
عندما تحتوي الأتمتة على أكثر من إجراء، تُشتق حالة status على المستوى الأعلى من نتائج كل إجراء بهذا الترتيب: auth_error إذا واجه أي إجراء خطأ مصادقة، ثم sent إذا قُبل أي إجراء، ثم deduplicated إذا كانت كل الإجراءات مُزالة التكرار، ثم skipped إذا كانت كل الإجراءات مكبوحة عمدًا (skipped أو deduplicated)، وإلا فـ failed. راجع actionResults[] للاطلاع على تفاصيل كل إجراء.
sent هي إيصال قبول من المنصة، وليست إيصال تسليم. يوسَم إجراء send_dm بـ sent في اللحظة التي تقبل فيها Meta الرسالة، سواء أُرسلت من حسابك على Instagram أو عبر Messenger من صفحة Facebook الخاصة بك. تسجّل الأتمتة هذا القبول فقط، ولا تتتبّع التسليم. لا يكشف Instagram تسليم الرسائل لأي واجهة برمجية، أما ما إذا كان المستلم سيستلمها فعليًا فيتوقف على إعداد Message requests الخاص به على Instagram، وهو ما لا يستطيع Ayrshare قراءته أو التأثير فيه. راجع رسالة أتمتة أُرسلت لكنها لم تُسلَّم.رموز الخطأ
تُعيد واجهة برمجة التطبيقات شكلين من الأخطاء:- أخطاء قواعد العمل تحمل رمز
codeمرقّم للأتمتة (مثل{ "action": "automation", "code": 469, ... }). - أخطاء التحقق — أي جسم طلب مشوّه (حقول مفقودة أو غير صالحة، متغيرات قوالب غير معروفة، مفاتيح غير مُعتمدة) — تُعاد كاستجابة واحدة
473مع كائنdetailsيُدرج الحقول المخالفة.detailsهي مخرجات المُحقِّق (formErrorsبالإضافة إلىfieldErrors). فرِّق بناءً علىdetails، وليس على رمز لكل حالة. فيfieldErrors، تكون المفاتيح هي حقول الطلب على المستوى الأعلى (triggers،actions): يُبلَّغ عن مشكلة داخل إدخال محدد، مثل مشغّل يفتقر إلىkeywords، تحت ذلك الحقل (مثلtriggers)، بينما يحملformErrorsالمشكلات على مستوى الكائن مثل المفاتيح غير المُعتمدة.
خطط Launch مشمولة أيضًا. يُعامَل Business Launch كمستوى Business، لذا فإن الأتمتة متاحة في خطط
Launch وBusiness وEnterprise. ولا يُعاد الرمز
468 إلا للخطط التي لا تتضمن الأتمتة.ما لا تسمح به Meta
بعض القدرات المطلوبة عادةً غير مدعومة لأن Meta لا تسمح بها في واجهة Instagram العامة:- رسالة خاصة تلقائية للمتابعين الجدد. لا يُصدر Instagram Webhook للمتابعة.
- الرسائل الخاصة الأولى للغرباء. تشترط Meta أن يكون المستلم قد تفاعل أولًا (تعليق، رد، رسالة خاصة، تفاعل) قبل أن يتمكّن حساب أعمال من مراسلته. كل مشغّل مدعوم مرتبط بمثل هذا التفاعل — لكن لاحظ أن كونك مسموحًا لك بالإرسال لا يعني أن الرسالة ستُسلَّم: إذ يمكن لإعداد Message requests الخاص بالمستلم على Instagram أن يجعل Meta تقبل الرسالة ثم تُسقطها بصمت (راجع رسالة أتمتة أُرسلت لكنها لم تُسلَّم).
- الحملات الصادرة الجماعية. تُطبَّق الحدود بالساعة للرسائل الخاصة وقواعد مكافحة الإساءة على مستوى المنصة.
الاستخدام متعدد الملفات الشخصية
تحترم نقاط النهاية ترويسةprofileKey. مرّر مفتاح ملف فرعي وستُنشأ/تُدار الأتمتة تحت ذلك الملف. تنقسم حدود المعدل بين الملفات الشخصية عبر حد فرعي لكل ملف شخصي بحيث لا يستنزف ملف شخصي كثير الحديث حصة الحساب الأصلي.
الأسئلة الشائعة
هل يمكنني الإطلاق عند وجود متابع جديد؟
هل يمكنني الإطلاق عند وجود متابع جديد؟
لا. لا يُصدر Instagram Webhook للمتابعة، ولا تسمح Meta لتطبيقات الأطراف الثالثة بإرسال رسالة خاصة إلى مستخدم لم يتفاعل أولًا. كل مشغّل مدعوم (
comment_keyword، story_reply، dm_reaction، dm_keyword) مرتبط بمثل هذا التفاعل، وهو ما يجعل الإرسال جائزًا.لماذا يظهر نشاط بحالة sent ومع ذلك لم يستلم المستلم الرسالة الخاصة؟
لماذا يظهر نشاط بحالة sent ومع ذلك لم يستلم المستلم الرسالة الخاصة؟
تعني
sent أن Meta قبلت الرسالة، وليس أنها سُلِّمت. ينطبق هذا على Instagram وعلى Facebook (عبر Messenger من صفحتك): تسجّل الأتمتة القبول فقط ولا تتتبّع التسليم. على Instagram، يعتمد التسليم على إعداد Message requests الخاص بالمستلم على Instagram — إذا لم يكن يسمح بطلبات الرسائل من الجميع، تُعيد Meta استجابة نجاح وتُسقط الرسالة بصمت، دون أي خطأ أو Webhook أو إشارة أخرى على أي واجهة برمجية. كما أن الرسالة الخاصة الناجحة المُشغَّلة بتعليق تصل بوصفها طلب رسالة يجب على المستلم قبوله (إلا إذا كانت هناك محادثة قائمة بالفعل). هذا قيد دائم في منصة Instagram. راجع رسالة أتمتة أُرسلت لكنها لم تُسلَّم.ماذا يحدث إذا كان رمز وصولي غير صالح عند إطلاق أتمتة؟
ماذا يحدث إذا كان رمز وصولي غير صالح عند إطلاق أتمتة؟
إذا فشلت فعلًا بيانات اعتماد Instagram أو صفحة Facebook الخاصة بالحساب أو أذونات المراسلة — على سبيل المثال رمز وصول منتهي الصلاحية أو مُلغى، أو عدم اختيار Facebook Page، أو عدم تفعيل Messaging للملف الشخصي — يُسجل صف النشاط الحالة
auth_error ولا يُعاد محاولة إرسال الرسالة الخاصة. تسمح معالجة حالة الحساب (إعادة الربط، أو اختيار Page، أو تفعيل Messaging) للتفاعل المطابق التالي بأن يُطلق بشكل طبيعي. ينطبق هذا فقط على إخفاقات بيانات الاعتماد والأذونات الحقيقية: إذا تعذّر تسليم رسالة خاصة محددة لسبب آخر — على سبيل المثال لم يُعثر على المستلم، أو أن التفاعل المُشغِّل جاء من الحساب نفسه الذي سيُرسل الرسالة الخاصة — يُسجل الصف بوصفه failed أو skipped مع السبب في actionResults[].errorDetails، ولن تُغيّر إعادة الربط النتيجة.لماذا يوجد تأخير قبل إرسال الرسالة الخاصة؟
لماذا يوجد تأخير قبل إرسال الرسالة الخاصة؟
يُجدوَل كل إرسال بعد 20 إلى 60 ثانية من التفاعل حتى تبدو رسائل DM طبيعية لأنظمة Instagram لمكافحة الرسائل غير المرغوبة. يُطبَّق هذا التأخير على التفاعل قبل مطابقة أي قاعدة، لذا يسري على كل إجراء في القاعدة، بما في ذلك
fire_webhook وsend_email — توقّع وصول الـ webhook بعد 20 إلى 60 ثانية من التعليق، لا فورًا. الختم الزمني created في صف النشاط هو وقت تطابق المشغّل؛ وcompletedAt هو وقت انتهاء الإرسال.هل تُحفظ صفوف النشاط إلى الأبد؟
هل تُحفظ صفوف النشاط إلى الأبد؟
تُحفظ صفوف النشاط إلى أجل غير مسمى للتتبع والتحليلات. تُعيد نقطة نهاية
GET /automations/:id/activity صفوف آخر 30 يومًا لأغراض الأداء. (يستخدم حارس إزالة التكرار نافذته الخاصة لكل إجراء — بشكل افتراضي 7 أيام — وهي غير مرتبطة بفترة استرجاع النشاط.)هل يؤدي حذف أتمتة إلى إزالة سجل نشاطها؟
هل يؤدي حذف أتمتة إلى إزالة سجل نشاطها؟
لا. الحذف هو حذف ناعم: يُوسَم السجل الرئيسي بـ
deleted، ولا تحدث عمليات إرسال جديدة، لكن تبقى صفوف النشاط التاريخية قابلة للقراءة عبر نقطة نهاية النشاط.نقاط النهاية
POST /automations— إنشاء أتمتة جديدةGET /automations— سرد الأتمتة الخاصة بكGET /automations/:id— جلب أتمتة واحدة مع مشغّلاتها وإجراءاتهاPUT /automations/:id— تحديث جزئي؛ إيقاف مؤقت عبرactive: falseDELETE /automations/:id— حذف ناعمGET /automations/:id/activity— سجل تدقيق الإرسال مع ترقيم صفحات بالمؤشر