واجهة استفسارات الموردين

قدّر تكلفة الشحن الدولي قبل أن يشتري العميل

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

وهذه البيانات غالبًا ما تكون غائبة أو غير موثوقة في صفحات المنتجات على 1688 وTaobao. وهو ما يترك عميلك أمام مشكلة عملية جدًا:

إنه يعرف سعر المنتج، لكنه لا يملك أي فكرة عن تكلفة إيصاله إلى بلده.

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

لماذا لا تكفي واجهة المنتجات

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

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

واجهة المنتجات تخبرك بما يعرفه السوق. أما استفسار المورد فيمنحك ما لا يمكن أن يؤكّده سوى المورد.

مثال: تقدير الشحن لأريكة

عميل في الولايات المتحدة يتصفّح أريكة من 1688 في تطبيقك، سعرها ¥800. أعادت واجهة المنتجات بالفعل المنتج والسعر والصور ووحدات SKU والخصائص — لكن دون وزن موثوق بعد التغليف أو أبعاد للطرود.

لذلك لا يستطيع تطبيقك الإجابة عن السؤال الوحيد المهم بعد ذلك:

سعر المنتج          ¥800
الشحن الدولي        ???

وفي المنتجات الضخمة، قد يتجاوز هذا المجهول بسهولة سعر المنتج نفسه.

يُنشئ تطبيقك استفسارًا:

POST /v1/supplier-inquiries
{
  "product_url": "https://detail.1688.com/offer/554456348334.html",
  "questions": [
    { "type": "packed_weight" },
    { "type": "package_dimensions" },
    { "type": "carton_info" }
  ]
}

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

الطرد 1   32 kg   110 × 75 × 55 cm
الطرد 2   18 kg    90 × 60 × 40 cm

تعود هذه الإجابات إلى تطبيقك على هيئة JSON منظّم، ويبدو المسار كاملاً هكذا:

منتج على 1688
      ↓  واجهة المنتجات
السعر: ¥800
      ↓  بيانات شحن موثوقة مفقودة
استفسار المورد
      ↓  HIOBuy تتواصل مع المورد الحقيقي
المورد يؤكد: طردان، 32 kg + 18 kg، وأبعاد الصناديق
      ↓  بيانات شحن منظّمة
تقدير الشحن الدولي (الصين ← الولايات المتحدة)
      ↓
العميل يرى تكلفة إجمالية تقريبية قبل الشراء

وهذا هو الهدف من كل ذلك:

تكلفة المنتج
+ الشحن الدولي المقدّر
= تكلفة واقعية قبل الشراء

موقعها بين واجهات HIOBuy

واجهة المنتجات            "ما هو المنتج، وكم يكلّف؟"
        ↓
واجهة استفسارات الموردين  "كيف سيغلّفه المورد فعليًا؟"
        ↓
عرض سعر الشحن            "كم ستبلغ تكلفة شحنه دوليًا تقريبًا؟"

استفسار المورد هو الطبقة المفقودة بين بيانات المنتج وعرض سعر الشحن.

أكثر من مجرد بيانات شحن

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

الحد الأدنى للطلب · المخزون · مدة التوريد · التغليف المحايد · التخصيص · بيانات الكرتونة · تفاصيل المنتج · وأي شيء آخر عبر النوع other.

فهي تمنحك اليوم بيانات التغليف ← تقدير الشحن، والاستدعاء نفسه يمكنه بالمثل أن يخدم معلومات المورد ← قرار الشراء. راجع أنواع الأسئلة للاطلاع على الأنواع العشرة جميعها ومخططات إجاباتها.

آلية العمل

1. يستدعي تطبيقك POST /v1/supplier-inquiries مع رابط المنتج، ووحدة SKU اختيارية، وسؤال واحد أو أكثر من الأسئلة ذات الأنواع المحددة.
2. تُنشئ HIOBuy الاستفسار وتسلّمه إلى خدمة التواصل مع الموردين.
3. يتواصل مشغّل موجود في الصين مع مورد ذلك العرض.
4. يردّ المورد.
5. يُحوَّل الرد إلى بيانات منظّمة وفق مخطط كل نوع من أنواع الأسئلة.
6. تستقبل نقطة النهاية لديك الحدث supplier_inquiry.message_answered، أو تستعلم دوريًا عبر GET /v1/supplier-inquiries/{id}.

الاستفسار هو محادثة وليس طلبًا لمرة واحدة. بمجرد إنشائه تواصل إضافة رسائل متابعة إلى المحادثة نفسها بدلاً من فتح محادثة ثانية.

المرفقات

بعض الأسئلة يسهل طرحها كثيرًا مع صورة. مرجع للتغليف، أو لقطة شاشة لوحدة SKU، أو رسم للأبعاد، أو ورقة مواصفات — وفي الاتجاه المعاكس: صورة التغليف من المورد نفسه، أو صورة للكرتونة، أو عرض سعر بصيغة PDF.

كل رسالة، سواء كانت منك أو من المورد، يمكن أن تحمل حتى خمسة مرفقات:

{
  "message": "Please ask the supplier whether they can use packaging similar to this.",
  "attachments": [
    {
      "type": "image",
      "url": "https://example.com/reference-packaging.jpg",
      "filename": "reference-packaging.jpg",
      "mime_type": "image/jpeg"
    }
  ]
}

القيمة type هي image أو document أو other. ويجب أن يكون الرابط بصيغة https://؛ وأي شيء غير ذلك يُرفض بالخطأ INVALID_ATTACHMENT_URL.

قد تتضمن ردود المورد مرفقات أيضًا. وتصل هذه المرفقات في مصفوفة attachments الخاصة بالرسالة وفي الحدث supplier_inquiry.message_answered، إلى جانب الإجابات المنظّمة. ولا ترى سوى المرفقات التي حدّدتها خدمة الاستفسارات على أنها من حقك الاطلاع عليها — أما ملفات عمل المشغّلين ولقطات محادثات الموردين فتبقى داخلية في الخدمة ولا تصل إلى الواجهة البرمجية أبدًا.

الوصول

استفسارات الموردين معطّلة افتراضيًا. تُفعّلها HIOBuy لكل تطبيق على حدة بعد إتمام الإجراءات التجارية — تواصل مع دعم HIOBuy لطلب الوصول.

إذا كانت القدرة غير ممنوحة أو موقوفة، تُرجع كل نقاط النهاية الخطأ 403 SUPPLIER_INQUIRY_NOT_ENABLED.

الأسواق المدعومة

أي رابط آخر يفشل بالخطأ UNSUPPORTED_MARKETPLACE. يُعرّف المنتج بالمزيج channel + source_product_id وليس بنص الرابط الخام، لذا تؤول الأشكال المختلفة لرابط العرض نفسه إلى المنتج ذاته.

حالات الاستفسار

تُعدّ الحالات pending وprocessing وwaiting_supplier وanswered نشطة. لا يجوز للتطبيق أن يحتفظ بأكثر من استفسار نشط واحد لكل منتج — وهذا ما يضمن وجود محادثة واحدة مع المورد لكل عرض. وإرسال طلب إنشاء لمنتج له استفسار بحالة completed أو failed يعيد فتح تلك المحادثة بدلاً من إنشاء واحدة جديدة.

Webhooks

سجّل نقطة نهاية في بوابة المطوّرين واشترك في فئة supplier_inquiry. يتبع التوقيع وإعادة المحاولة قواعد Webhook القياسية.

تحمل كل حمولة الحقلين inquiry_id وproduct.{channel,source_product_id}.

رموز الأخطاء

الرمز SUPPLIER_INQUIRY_SERVICE_UNAVAILABLE عام عن قصد: لا يتم الكشف عن الأسباب المتعلقة بالمزوّد مثل الرصيد أو حالة الحساب. اذكر قيمة request_id عند التواصل مع الدعم.

نقاط النهاية