# تقديم Auto: endpoint واحد لأي هدف

> URL: https://foura.ai/ar/blog/auto-endpoint
> Updated: 2026-09-27
> Index: https://foura.ai/llms.txt

## ما الجديد

أصبح endpoint `/api/auto` الآن أقصر مسار للحصول على response صالح لأي URL. وجّهه نحو الهدف. يختار Auto تلقائيًا ما إذا كان سينفّذ الـ request عبر Single أو Proxy Finder أو Browser، ويتعامل مع عمليات الفحص الخاصة بالصفحة عند مواجهتها، ثم يعيد session يمكن لطلبك التالي إعادة استخدامها.

‏endpoint واحد. أي هدف. دون الحاجة إلى تبديل الأوضاع من جانبك.

هذه هي الفكرة بالكامل. يوضح باقي هذا المقال آلية العمل، والتكلفة، والحدود التقنية التي يجب الانتباه لها.

## آلية العمل

يعتمد Auto على تسلسل متدرج من المستويات (الأقل تكلفة أولًا، والأعلى تكلفة أخيرًا). مع كل request، يتدرج Auto صعودًا عبر هذه المستويات حتى يقدّم أحدها response تقبله قواعد `validate` الخاصة بك.

المستويات، بالترتيب:

1. **Cached session.** إذا كان لدى Auto جلسة جاهزة (warm session) لهذا الـ host من طلب سابق، فإنه يعيد تنفيذ الطلب من خلالها أولًا. هذا هو المسار الأقل تكلفة.
2. **Proxy Finder.** طلب proxy مع تدوير العناوين. مناسب للمواقع المحمية أساسًا بناءً على سمعة الـ IP.
3. **Browser.** معالجة كاملة (full render) تنفّذ JavaScript، وتجتاز عمليات الفحص التي تطلبها الصفحة، وتجمع ملفات الـ cookies التي يصدرها الموقع.

بمجرد نجاح أحد المستويات، يخزّن Auto الـ session التي حصل عليها: معرّف الـ proxy المستخدم، وملفات الـ cookies الصادرة عن الموقع، وUser-Agent. في الطلب التالي لنفس الـ host، يجرّب Auto هذه الـ session أولًا. إذا كانت لا تزال صالحة، فستدفع تكلفة المستوى الأرخص بدلًا من المستوى الأعلى تكلفة.

نموذج استدعاء أساسي:

```bash
curl -X POST "https://api.foura.ai/api/auto" \
  -H "X-API-Key: pk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/data",
    "validate": { "status": { "accept": [200] } }
  }'
```

A response مقتطع:

```json
{
  "status": 200,
  "data": "...",
  "headers": [...],
  "meta": {
    "rung": "cache",
    "solved": false,
    "attempts": 1,
    "credits": 2
  },
  "session": {
    "proxy": "CLN1B8",
    "cookies": [{ "name": "cf_clearance", "value": "..." }],
    "userAgent": "..."
  }
}
```

هناك حقلان مهمان لما ستبنيه بعد ذلك. يوضح لك `meta.rung` المسار الذي نجح. بينما `session` هو الثلاثية التي يمكنك تمريرها إلى استدعاء `/api/single` لإعادة استخدام نقطة الخروج نفسها بنفسك. حقل `proxy` هو معرف base36 مبهم (لا يحتوي على عناوين IP خام)، وهو آمن للتسجيل في السجلات وللتمرير بين الأنظمة.

## الأثر

هناك رقمان مهمان هنا.

يقوم أول استدعاء لموقع محمي بتشغيل مرحلة Browser: التصيير، والحل، وجمع ملفات cookie، وتسليمك الصفحة. يستهلك ذلك حوالي 10 أرصدة. بمجرد أن يخزن Auto جلسة عمل صالحة لذلك المضيف في الذاكرة المؤقتة، تعيد الاستدعاءات اللاحقة استخدامها: عبر Single بمقابل رصيدين (2)، أو عبر Proxy Finder بمقابل 4 أرصدة عندما تعمل ملفات cookie الخاصة بالجلسة من أي عنوان. وبالتالي، يكون الاستدعاء الثاني أرخص بنسبة تصل إلى 5 أضعاف مقارنة بالأول، وتستمر كل الاستدعاءات اللاحقة في دفع السعر المنخفض طالما بقيت الجلسة صالحة. قمنا بقياس هذا في بيئة الإنتاج أثناء الإطلاق: نقاط الخروج التي لا تتطلب cookie (بمجرد العثور عليها) تعيد التنفيذ بتكلفة رصيدين (2) فقط لكل استدعاء، مقارنة بـ 10 أرصدة كانت تُستهلك عندما كان كل request يمر عبر Proxy Finder.

الرقم الثاني: المراحل الفاشلة لا تُحسب تكلفتها. إذا جرب Auto ثلاثة proxies وأرجع كل منها رمز 403 قبل أن ينجح الرابع في التسليم، فسيتم احتساب أرصدة الرابع فقط. أنت تدفع مقابل المحتوى الذي تم تسليمه، وليس مقابل عملية البحث.

هذه هي القيمة الأساسية. تعمل المرحلة المكلفة مرة واحدة، وتعمل المرحلة المنخفضة التكلفة دائما بعد ذلك، دون أن تضطر لكتابة منطق التخزين المؤقت بنفسك.

هناك سلوكان آخران يستحقان الإشارة إليهما لأنهما يحلان مشكلات حقيقية في بيئة الإنتاج:

**الأهداف المقيدة جغرافيا تتوقف عن إهدار نقاط الخروج.** عندما يرجع موقع ما الرمز 451 (أو صفحة وسيطة للحجب القانوني) لمعظم نقاط الخروج، يتعلم Auto أي البلدان نجحت بالفعل في تسليم المحتوى. وفي الاستدعاء التالي، يسحب نقاط خروج جديدة من تلك البلدان أولا ويوزع الحمل المتزامن عبرها. وبذلك لا يتم تكثيف الضغط على نقطة خروج واحدة حالفها الحظ والوصول إلى حد معدل الطلبات (rate limit).

**يعمل Validate على كل مرحلة.** صفحة المحتوى الخاطئ (مثل قيود الدولة التي ترجع كود الحالة 200 مع إشعار قانوني في body) لا تُحسب كنجاح أبدا. إذا كان `validate.data.fail` الخاص بك ينص على "legal reasons"، يواصل Auto المحاولة حتى تجتاز إحدى المراحل هذا الشرط. لا يعتمد المرحلة المخزنة مؤقتا، ولا يعتمد أي مرحلة دون تحقق. وإذا لم ينجح أي مسار، فستحصل على فشل صريح يوضح السبب الحقيقي.

## للمستخدمين المتقدمين

بعض الإعدادات المهمة بمجرد زيادة حجم الاستخدام عبر Auto.

يعبر `timeout_ms` عن ميزانية العملية بأكملها، وليس لكل مرحلة على حدة. القيمة الافتراضية هي 120 ثانية. يقوم Auto بتقسيمها: يحصل كل استدعاء فرعي على القيمة الأقل بين مهلته الزمنية الطبيعية والميزانية المتبقية، ويتوقف تسلسل المحاولات عن إطلاق مراحل جديدة بمجرد أن يتبقى وقت قليل جدا. اضبط القيمة على 20,000 لأعمال زمن الاستجابة التفاعلي. واترك القيمة الافتراضية لعمليات الزحف المجمعة التي تتحمل استجابات أطول.

يكون `forceProxy` مفعلا افتراضيا. لا يتصل Auto أبدا بالهدف من عنوان IP الأصلي لـ FourA إلا إذا قمت بضبط `forceProxy: false`. تنبيه واحد: بعض المواقع (مثل Cloudflare التفاعلي المزود بنظام تقييم موثوقية عنوان IP) تعمل في الواقع بشكل أفضل من عنوان IP نظيف لمركز بيانات مقارنة بنقطة خروج سكنية منخفضة الموثوقية. لذلك، يمكن أن يجعل `forceProxy: false` الوصول إلى أهداف معينة أسهل، وليس أصعب. إذا كنت تواجه تحديات متكررة على مضيف معين، فإن تجربة إيقاف هذا الخيار تستحق المحاولة.

`ignoreProxies` هي قائمة استبعاد من جانب العميل. مرّر معرّفات proxy التي تأكدت من حظرها (من استجابة `session.proxy` سابقة واجهت rate limit من جانبك)، وسيتخطاها Auto تماماً: عند إعادة استخدام الجلسات النشطة، والبحث عن عقد الخروج، وأثناء الاستدعاء الفرعي لـ Proxy Finder. وبذلك لن يختار Auto مجدداً عقدة الخروج التي طلبت منه تجنبها.

تتيح لك `meta` أيضاً إنشاء لوحات تحكم خاصة بك: لمعرفة أي المضيفين احتاجوا إلى طبقة المتصفح اليوم، ومتوسط المحاولات لكل تسليم، ونسبة عمليات الجلب التي تطلبت حل التحديات مقارنة بالعمليات النظيفة. إذا ارتفعت تكلفة مضيف معين فجأة من 2 credits إلى 10، فهذه إشارة لتدهور الجلسة يمكنك معالجتها قبل أن تتأثر فاتورتك.

مثال يجمع بين الخيارات الأربعة:

```python
import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"X-API-Key": "pk_live_..."},
    json={
        "url": "https://example.com/product/9876",
        "timeout_ms": 30000,
        "forceProxy": True,
        "ignoreProxies": ["CLN1B8", "K7X9AB"],
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ['"price":'], "fail": ["captcha", "legal reasons"]}
        }
    }
).json()

# If Auto delivered, keep the session for the next call to this host
if r.get("status") == 200 and "session" in r:
    session = r["session"]                              # {proxy, cookies, userAgent}
    print(r["meta"]["rung"], r["meta"]["credits"], r["meta"]["attempts"])
```

بالنسبة لمخطط `validate` نفسه، راجع الشرح السابق في [Validate Rules Now Decide What Counts as Success](https://foura.ai/blog/validate-decides-success).

## ما التالي

يوجد أمران على خارطة طريق Auto حاليًا.

فحص الجلسات سيتوفر في Dashboard قادمًا. حاليًا، الجلسات التي يحتفظ بها Auto لكل host تظل داخل الخدمة، ولا يوجد ما يمكنك الاطلاع عليه أثناء تصحيح أخطاء الاستهلاك من جانبك. نعمل على ربط واجهة لعرض الجلسات لكل host حتى تتمكن من رؤية الجلسات المخزنة مؤقتًا، وأعمارها، والمدة المتبقية لصلاحيتها، وسجل الـ rung خلف كل منها. بالإضافة إلى زر لإسقاط الجلسة يدويًا عند تغير الهدف ومعرفتك بأن الـ cache غير صحيح.

بعد ذلك، تحكم أكثر إحكامًا في التكاليف. حد أقصى صارم للرصيد لكل request (عدم إنفاق أكثر من X في هذا الاستدعاء إطلاقًا، والفشل بصراحة إذا تطلب الأمر أكثر من ذلك) ووضع "single-only" للفرق التي لا تحتاج أهدافها أبدًا إلى الـ browser rung. كلاهما متاح خلف flags حاليًا.

الهدف من Auto هو ألا تضطر للتفكير في المنتج الذي يجب استدعاؤه. هذا لا يعني أنه لا يمكنك فحص ما حدث. كل response يتضمن الـ rung المستغرق والجلسة التي أنشأها. اقرأ هذين الحقلين وستعرف بدقة سبب تكلفة استدعاءاتك.