🔗 مختبِر ويب هوك IFTTT ☆

اختبر ويب هوكس IFTTT دون مغادرة متصفحك

أداة اختبار ويب هوك IFTTT مجانا يرسل طلب POST مباشرة إلى maker.ifttt.com باسم الحدث والمفتاح وحتى ثلاث قيم JSON, تماماً كما يتوقع الـapplet. مفيد لتشخيص الأتمتة والتحقق من المفاتيح والتأكد من وصول البيانات إلى خدمتك.

كيف تختبر applet

• أنشئ applet من نوع Webhooks في IFTTT وانسخ المفتاح من صفحة الخدمة
• أدخل اسم الحدث والمفتاح بالأعلى
• أضف value1, value3 إن كان الـapplet يستخدمها ثم أرسل

ملاحظات مهمة

• ينطلق الطلب من متصفحك مباشرة إلى IFTTT, بدون وسيط
• نجاح الاختبار يعني فقط أن IFTTT قبل المُشغِّل؛ راجع سجل الـapplet للتحقق من التنفيذ
• مفتاحك لا يُخزَّن ولا يُسجَّل أبداً

كيف تعمل اختبارات الـwebhook

‏webhooks في IFTTT نقاط HTTPS بسيطة: المفتاح في المسار وجسم JSON اختياري يحمل حتى ثلاث قيم. يرسل المُختبِر طلباً حقيقياً من متصفحك (وقد تكون الاستجابة معتمة بسبب CORS) ويبلغ بحالة HTTP والزمن والاستجابة المقروءة حيث تسمح. تؤكد الاستجابة 200 صحة المفتاح واسم الحدث؛ و401 و404 تشيران إلى مفتاح أو حدث خاطئ. ولا يثبت الاختبار تنفيذ إجراء الـapplet.

الصيغ والحدود والمعاملات

الخصوصية: لا شيء يمر عبر 0Appz

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

قائمة تشخيص الـwebhooks

• تحقق من مطابقة اسم الحدث تماماً؛ الحروف حساسة لحالة الأحرف.
• أعد نسخ المفتاح من صفحة Webhooks: المسافات تكسره.
• تأكد من أن الـapplet متصل ومفعّل.
• قد يخفي CORS الاستجابة حتى مع النجاح: راجع سجل النشاط.
• جدّد المفتاح إن ألصق يوماً في أداة غير موثوقة.

اقرأ أيضاً أدوات المطورين للترويسات والـwebhooks وتصحيح API.

الويب هوك والحمولات ورموز الاستجابة

الويب هوك مجرد طلب HTTP يرسله خدمة إلى رابط تتحكم به، واختباره يعني إعادة إنتاج ذلك الطلب بأمانة. الطريقة دائماً تقريباً POST والجسم عادة JSON، لذا يجب أن يذكر ترويسة Content-Type القيمة application/json وإلا فقد ترفض الأتمتة المستقبِلة الحمولة. وخدمة Webhooks في IFTTT حالة خاصة: تقبل ثلاثة قيم باسم value1 وvalue2 وvalue3، تُرسل كجسم JSON أو كحقول نموذج مرمزة في الرابط. والبقاء داخل هذه الحقول الثلاثة هو قيد التصميم الأساسي، فاحزم البيانات المنظمة في سلسلة JSON واحدة داخل value1 عندما تحتاج أكثر. وتخبر رموز الاستجابة بما حدث: 200 تعني أن الخدمة قبلت الحدث، و400 تعني غالباً JSON مشوهاً أو حقلاً ناقصاً، و401 أو 403 أن المفتاح خاطئ أو ملغى، و404 أن اسم الحدث غير موجود. أما 500 فهي مشكلة الخدمة لا مشكلتك، وإعادة المحاولة معقولة. وملاحظتان تشغيليتان: كثير من الخدمات تزيل تكرار الحمولات المتطابقة، فقد لا يعمل اختبار يرسل الجسم نفسه مرتين إلا مرة واحدة، وقد تخزن الوسائط الشبكية الطلبات أو تحجبها دون الترويسات الصحيحة. وعند الاختبار تحقق من جسم الاستجابة لا من رمز الحالة فقط، لأن بعض الواجهات تعيد 200 مع كائن خطأ بداخلها.