خطأ API 422 لإرسال دعوات البريد الإلكتروني للمستخدمين الذين لديهم حساب موجود

مرحباً بالفريق،

أحاول إعداد أتمتة عبر Make.com لدعوة المستخدمين الذين يشترون منتجًا جديدًا من Kajabi تلقائيًا إلى Discourse مع إضافتهم إلى مجموعة جديدة.
المشكلة هي أن معظم (وليس كل!) الأشخاص الذين يقومون بهذه المشتريات لديهم بالفعل حساب في منتدانا. بناءً على قراءة عدد من المشاركات الأخرى المتعلقة بخطأ 422، بما في ذلك المشاركة المرتبطة أدناه من عام 2021، أعتقد أن الخطأ يحدث لأن رسائل البريد الإلكتروني مرتبطة بالفعل بحساب في Discourse.
Error 422 when sending invite on 2.7.0.beta4

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

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

 {
  "email": "user@host.com",
  "skip_email": false,
  "max_redemptions_allowed": 1,
  "topic_id": 782,
  "group_names": "Group-Name"
}

هل الأمر بسيط مثل تغيير “false” إلى “true” في قسم “skip_email”؟ أم أن ذلك لن يرسل دعوات لمن ليس لديهم حساب؟

أرى أيضًا وظيفة PUT لإضافة مستخدم إلى مجموعة، ولكني أعمل فقط مع رسائل البريد الإلكتروني المرسلة عبر webhook من Kajabi ولست متأكدًا من كيفية إعداد طريقة للتحقق من رسائل البريد الإلكتروني بحثًا عن أسماء المستخدمين للقيام بذلك نظرًا لأنني لا أستطيع استخدام عنوان البريد الإلكتروني لوظيفة PUT على ما يبدو.

شكراً على أي مساعدة!

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

يمكنك هندسة Discourse API عكسيًا واستخدام المسار admin/users والبحث عن المستخدم عبر عنوان بريده الإلكتروني والمتابعة من هناك؟

شكراً على الرابط والاقتراح. يبدو أن هذا يتجاوز قدراتي قليلاً، لكنني سأرى ما يمكنني فعله دون كسر أي شيء.

هل هناك سبب لعدم إمكانية حل هذا بنفس الطريقة التي يتم بها التعامل مع الدعوات المجمعة عبر ملف .csv عندما يكون هناك مستخدمون موجودون بالفعل دون إحداث خطأ في العملية بأكملها؟ يبدو أنه يجب أن تكون هناك طريقة بسيطة للقيام بذلك عن طريق تضمين سطر “إذا كان المستخدم موجودًا، فتجاوز الدعوة” أو شيء من هذا القبيل في واجهة برمجة التطبيقات (API)…