واجهة X للبث تدير الجدولة والدردشة: الوصول يظل بالموافقة

في 22 سبتمبر 2026، أطلقت X نسخة معاد بناؤها من Livestream API تتيح للتطبيقات المعتمدة جدولة البث المباشر وإدارة دردشته، وفق دليل Upstream للبث على X. يتيح الإطلاق لمزودي أدوات الإنتاج إدارة مراحل أكثر من العرض داخل تطبيقاتهم، لكنه لا يمنح كل مبدع أو مطور وصولًا برمجيًا تلقائيًا.

توضح وثائق Livestream API من X أن الواجهة تشمل مصادر فيديو دائمة عبر RTMP وRTMPS، وإنشاء البث ونشره وإنهاءه، وجدولته، وقراءة رسائل الدردشة وإرسالها والإشراف عليها. وتطلب الوثائق تقديم نموذج وصول لتراجعه X؛ لذا يتعلق الإعلان بقدرات التطبيقات التي تحصل على الموافقة، لا بإتاحة مفتاح برمجي لكل حساب.

من مصدر الفيديو إلى انتهاء العرض

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

يبدأ المسار المعتاد بإنشاء المصدر وتشغيل برنامج الترميز لإرسال الفيديو إليه، ثم إنشاء جلسة البث ونشرها على X ومتابعة حالتها وإنهائها. يوفر RTMPS اتصالًا مشفرًا إلى جانب RTMP. لكن إرسال الإشارة إلى عنوان الاستقبال لا يعني وحده أن العرض أصبح منشورًا للمشاهدين؛ فاستقبال الفيديو والتحكم في حالة الجلسة وظيفتان منفصلتان.

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

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

الموافقة على التطبيق لا تحل محل صلاحية الحساب

تصف تغطية Net Influencer الواجهة بأنها موجهة أساسًا إلى مزودي برمجيات البث وفرق الإنتاج التي تريد إدارة دورة العرض عبر أدواتها. وتؤكد أن المطور يحتاج إلى تقديم طلب وصول قبل استخدام نقاط النهاية. لهذا قد يستفيد المبدع من الوظائف الجديدة داخل أداة وافقت عليها X، من دون أن يبني تكاملًا برمجيًا بنفسه.

هناك إذنان مختلفان في هذا المسار: اعتماد تطبيق شركة البرمجيات للوصول إلى Livestream API، وتفويض حساب المستخدم الذي سيملك البث. تستخدم الطلبات تفويضًا في سياق ذلك المستخدم، ويجب أن يطابق الحساب المفوض الحساب المحدد في طلب إدارة العرض. كما يجب أن يملك الحساب صلاحية البث المباشر؛ والحسابات ذات المنشورات المحمية لا تستطيع إنشاء بث عبر الواجهة.

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

ما الذي يبقى في Live Studio؟

يبقى Live Studio مسارًا مباشرًا للمبدع الذي يدير عرضه من أدوات X على الحاسوب. ينشئ فيه مصدرًا، ويحصل على عنوان الاستقبال ومفتاح البث، ثم يرسل الفيديو من برنامج ترميز أو خدمة بث ويبدأ العرض أو يحدد موعده. ويرتبط الوصول إلى Live Studio على الحاسوب باشتراك X Premium؛ فهذا إعداد مختلف عن طلب شركة برمجيات الوصول إلى Livestream API.

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

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

الأثر على أدوات الإنتاج والبث المتعدد

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

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

المؤكد بعد الإطلاق هو اتساع ما تستطيع التطبيقات المعتمدة إدارته عبر Livestream API، مع بقاء الوصول إليها مشروطًا بمراجعة X. أما أسماء المزودين الذين سيحصلون على الموافقة، والوظائف التي ستظهر فعلًا في منتجاتهم، فتتوقف على قرارات الوصول والتنفيذ لدى كل مزود. ولا يترتب على إتاحة الواجهة للمطورين تغيير تلقائي في مسار المبدع الذي يبث من Live Studio.

اقرأ أيضًا:

• Watch With يوزّع الدخل والمشاهدات بين بثين: الوصول ما زال تجريبيًا
• Gemini يعمل بين تطبيقات Workspace، لكن الوصول يتوقف على إعدادين
• Gemini Enterprise يضيف الدفع حسب الاستخدام، لكن الوصول ما زال انتقائيًا