1. الوصول عبر واجهة البرمجة فقط
تصل PostEngine إلى بيانات لينكد إن حصريًا عبر واجهة REST الرسمية. ولا نمارس ما يلي:
- سحب محتوى صفحات لينكد إن آليًا أو نسخ ما يظهر على الشاشة
- التصفح الآلي أو استخدام متصفح بلا واجهة رسومية للتفاعل مع لينكد إن
- الهندسة العكسية لواجهات لينكد إن الخاصة أو بروتوكولاتها
- التحايل على آليات المصادقة أو حدود الطلبات في لينكد إن
2. نطاقات الصلاحيات (OAuth) وتقليل جمع البيانات
لا نطلب إلا الحد الأدنى من نطاقات الصلاحيات اللازمة لتقديم الخدمة:
- openid — التحقق من الهوية عبر OpenID Connect (مطلوب من لينكد إن)
- profile — قراءة الاسم الظاهر للعموم وصورة الملف الشخصي والمسمّى المهني لعرضها في الحساب
- email — قراءة عنوان البريد الإلكتروني لربط الحساب والإشعارات
- w_member_social — نشر المنشورات على صفحة العضو في لينكد إن. ولا يُنشر أي منشور إلا بعد موافقة المستخدم عليه داخل التطبيق، أو بناءً على تعليمات دائمة منه إذا ضبط وضع النشر في مساحة عمله على النشر التلقائي.
ولا نطلب نطاقات تتجاوز حاجتنا أبدًا. وإذا منحت لينكد إن نطاقات إضافية، فلا نصل إلى بيانات خارج غرضنا المعلن.
3. الالتزام بحدود الطلبات
تلتزم PostEngine بحدود الطلبات التزامًا كاملًا:
- نلتزم برأس Retry-After من لينكد إن: عند استجابة 429 أو 503 تُعاد المحاولة في الوقت الذي تحدده لينكد إن بالضبط، وذلك في كل طابور عمل يتصل بالواجهة: النشر، ومزامنة التحليلات، ومزامنة التعليقات، والردود التلقائية. ونقرأ كذلك رؤوس X-RateLimit-* في كل استجابة ونحفظها لكل حساب، ونعمل بها قبل الطلب التالي لذلك الحساب: فإذا هبط المتبقي دون عشرة بالمئة أوقفنا مزامنة التحليلات والتعليقات لذلك الحساب حتى تتجدد الحصة في الوقت الذي تحدده لينكد إن، وباعدنا بين طلبات النشر والردود بما يصل إلى عشر ثوانٍ للطلب الواحد بدل تأجيلها؛ وإذا لم يبقَ رصيد انتظر كل طلب لذلك الحساب حتى تتجدد الحصة. وعند هذه النسبة نفسها يصدر تنبيه.
- حدود نشر لكل اتصال: ثلاثون ثانية على الأقل بين منشورين على الاتصال نفسه، ومئة منشور كحد أقصى لكل اتصال في اليوم، ويُطبَّق الحدّان قبل إرسال الطلب. وفوق ذلك حصص على مستوى مساحة العمل تحدّ من النشر والتعليق، فلا يستنفد عميل واحد حدًّا مشتركًا.
- تباعد أسّي بين المحاولات مع تفاوت عشوائي عند الأخطاء المؤقتة (429 و503) في كل طابور يتصل بلينكد إن، حتى لا تعيد مساحات العمل المحاولة كلها في اللحظة نفسها عند بلوغ حدٍّ واحد. وإذا حدّدت لينكد إن وقت إعادة المحاولة فوقتها هو المعتمد، لا التباعد المحسوب.
- فترات انتظار بين عمليات قراءة التحليلات: خمس وأربعون دقيقة لكل منشور، وأربع ساعات لكل حساب مرتبط، ومدد أطول بعد أن ترفض لينكد إن قراءةً ما، وهي ست ساعات أو أربع وعشرون عند الرفض الدائم.
4. احترام خصوصية المستخدم
نحترم إعدادات خصوصية أعضاء لينكد إن:
- نصل فقط إلى البيانات التي أذن بها المستخدم المتصل صراحةً عبر موافقة OAuth
- لا نصل إلى بيانات أعضاء لينكد إن الآخرين ولا نخزّنها، بخلاف مقاييس التفاعل الظاهرة للعموم (عدد الإعجابات والتعليقات) على منشورات المستخدم نفسه
- يمكن للمستخدم فصل حسابه في لينكد إن في أي وقت. وعندها نستدعي فورًا نقطة إلغاء الرمز لدى لينكد إن، ونضع الاتصال في حالة ملغى، ونفصله عن كل منشور معلّق. وإذا رفضت لينكد إن الإلغاء أبلغنا المستخدم بأن الرمز لم يُلغَ بدل أن نُظهر نجاحًا، وسجّلنا الإخفاق على الاتصال؛ ويُحتفظ بالرمز المشفّر لغرض إعادة محاولة الإلغاء وحده، ولا يُستخدم بعد ذلك في أي اتصال بلينكد إن.
- عند حذف الحساب، تُحذف جميع البيانات المشتقة من لينكد إن نهائيًا خلال 30 يومًا
5. معايير المحتوى والنشر
تضمن PostEngine نشرًا مسؤولًا للمحتوى:
- لا يُنشر شيء على لينكد إن إلا بموافقة المستخدم عليه داخل التطبيق، أو بعد أن يضبط وضع النشر في مساحة عمله على النشر التلقائي. والنشر التلقائي معطّل افتراضيًا، ويختاره مالك الحساب من الإعدادات، وله إيقافه في أي وقت، ويُسجَّل كل تغيير فيه في سجل التدقيق لدينا مع اسم المستخدم ووقت التغيير. وما دام مفعّلًا، تُنشر المسودات التي تتجاوز عتبة الجودة المحددة في مساحة العمل بناءً على تلك التعليمات الدائمة دون نقرة موافقة على كل منشور. ويتلقّى المستخدم إشعارًا قبل نشر كل منشور منها، ويُؤخَّر نشره خمس عشرة دقيقة على الأقل من لحظة جدولته؛ ويحمل الإشعار الوقت الذي يصل فيه المنشور إلى لينكد إن بالضبط، وله حتى ذلك الوقت أن يوقف ذلك المنشور تحديدًا من الإشعار نفسه. وإذا تعذّر علينا إيصال ذلك الإشعار فإننا لا ننشر المنشور، بل نعيده إلى مسوداته لمراجعته، ونسجّل الامتناع عن النشر في سجل التدقيق لدينا. وإن كان النشر قد بدأ فعلًا لحظة الضغط، نخبره بذلك ولا ندّعي أننا أوقفناه، ويُسجَّل كل إيقاف وكل رفض في سجل التدقيق لدينا مع اسم المستخدم ووقته.
- المحتوى المُولّد بالذكاء الاصطناعي يُكتب دائمًا في مسودة أولًا، ولا يُنشر مباشرة من النموذج. وفي وضعَي موافقة المسودة والموافقة الجماعية، وأولهما الوضع الافتراضي، لا يصل المحتوى إلى لينكد إن دون مراجعة بشرية. وفي وضع النشر التلقائي لا يُنشر إلا بعد تجاوز عتبة الجودة المحددة في مساحة العمل؛ وما لا يتجاوزها لا يُنشر تلقائيًا أبدًا ويبقى للمراجعة.
- نحظر الرسائل المزعجة والتفاعل المزيف وأي محتوى يخالف سياسات المجتمع المهني في لينكد إن، ونمنعها فعليًا
- وإلى جانب ذلك، يستطيع المنتج صياغة ردود بالذكاء الاصطناعي على التعليقات الواردة على منشورات العضو نفسه. وإرسال هذه الردود تلقائيًا معطّل على مستوى المنصة كلها، ولم يُرسل أي رد بهذه الطريقة قط. ولو فُعّل، لما أُرسل الرد تلقائيًا إلا بعد أن يفعّل مالك الحساب الرد التلقائي، وهو معطّل افتراضيًا، وضمن عتبة جودة وحدٍّ يومي وحدٍّ لكل معلّق؛ وما عدا ذلك يبقى ليرسله العضو بنفسه. والرد الذي يتجاوز هذه الحدود يُحتجز خمس عشرة دقيقة من لحظة جدولته، ويُعرض نصه على العضو قبل خروجه، فيستطيع إيقاف ذلك الرد بعينه من الإشعار نفسه. وإذا كان الإرسال قد بدأ فعلًا حين يضغط الزر، أخبرناه بذلك ولا ندّعي أننا أوقفناه. ويُدوَّن في سجل التدقيق كل إرسال تلقائي وكل إيقاف وكل رفض، مع المستخدم ووقت الحدث.
6. أمان البيانات
نحمي بيانات لينكد إن بإجراءات أمان وفق معايير القطاع:
- تُشفَّر رموز وصول OAuth الخاصة بلينكد إن ورموز التحديث أثناء التخزين بخوارزمية AES-256-GCM
- جميع اتصالات واجهة البرمجة تستخدم تشفير TLS
- يجري تحديث الرموز وفق آلية OAuth 2.0 القياسية من لينكد إن، مع تخزين آمن
- الوصول إلى بيانات لينكد إن مقصور على المستخدمين المسجّلين، ولا يرى أحدهم إلا بياناته
7. التواصل
للأسئلة المتعلقة بممارسات استخدام واجهة البرمجة لدينا، تواصل معنا على [email protected].