בדיקת solvethree ב-Postman
ייבאו את אוסף Postman ללא פרטי גישה, הגדירו ערכי סביבה פרטיים ושלחו את הבקשה ליצירת משימה פעם אחת. לאחר מכן השתמשו בבקשה לאחזור משימה כדי לבדוק את אותה משימה עד שתסתיים. האוסף לא כולל בדיקות או סקריפטים אוטומטיים ששולחים משימות נוספות.
בדף הזה
ייבוא האוסף והגדרתו
- 1.
ייבאו את ה-JSON שהורדתם
ב-Postman, בחרו באפשרות הייבוא ובחרו את קובץ האוסף. הוא מכיל בקשות ליצירת משימה ולאחזור משימה עם הרשאת Bearer בירושה ומצייני מיקום למשתנים.
- 2.
בדקו את פרופיל האתר
לסביבת העבודה שלכם דרוש פרופיל פעיל לשם המארח של היעד. הגדירו אותו במסוף לפני הבדיקה; שליחת שם מארח ופעולה לא יוצרת פרופיל. ראו הגדרת פרופיל אתר.
- 3.
הגדירו ערכי סביבה פרטיים
צרו ובחרו סביבה לבדיקה הזו. הזינו את הערכים הבאים באופן פרטי, כולל פרטי גישה לפרוקסי אם ישנם. אל תכניסו סודות ישירות לאוסף ואל תייצאו סודות שהוזנו.
- 4.
הגדירו הרשאת Bearer
ברמת האוסף, בחרו באפשרות טוקן Bearer והפנו למשתנה סביבה פרטי שמכיל את מפתח ה-API של סביבת העבודה שלכם. השאירו את שתי הבקשות מוגדרות לקבלת הרשאה בירושה. ה-API מצפה ל-Authorization: Bearer ואחריו המפתח הזה.
| משתנה | מה להזין |
|---|---|
| SOLVETHREE_API_KEY | מפתח ה-API הפרטי של סביבת העבודה שלכם. טוקן ה-Bearer של האוסף מפנה למשתנה הזה. |
| SITE | שם המארח של היעד, לא כתובת URL מלאה של דף. |
| ACTION | פעולת ה-reCAPTCHA שבה משתמשת הבקשה ליעד. |
| PROXY | כתובת ה-URL של פרוקסי HTTP או HTTPS לבדיקה הזו, כולל פרטי גישה אם נדרשים. |
| REQUEST_ID | ערך חדש לכל משימה לוגית חדשה: 1–64 תווים הכוללים אותיות ASCII, ספרות, קווים תחתונים או מקפים. |
| TASK_ID | השאירו ריק בהתחלה. לאחר היצירה, העתיקו לכאן את ה-id שהוחזר. |
שלחו את הבקשה ליצירת משימה פעם אחת
פתחו את הבקשה ליצירת משימה. היא שולחת POST אל https://api.solvethree.com/v1/tasks עם גוף JSON גולמי שמאוכלס מתוך הסביבה שבחרתם.
{
"site": "{{SITE}}",
"action": "{{ACTION}}",
"proxy": "{{PROXY}}",
"requestId": "{{REQUEST_ID}}"
}הבקשה הזו משתמשת ב-reCAPTCHA Enterprise v3 כברירת מחדל. אל תוסיפו שדה type או url. היא מספקת proxy יחיד, ולכן אל תוסיפו גם proxyCandidates: נדרש בדיוק אחד מהשדות האלה.
הגדירו את REQUEST_ID לפני השליחה, ואז לחצו על שליחה פעם אחת. בדקו תחילה את תגובת ה-HTTP. אם היא אינה מוצלחת, בדקו את שגיאת הבקשה במקום להתייחס לגוף התגובה כתגובת משימה מוצלחת. תקנו קלט לא תקין במקום לשלוח אותו שוב ושוב ללא שינוי.
בתגובת יצירה מוצלחת, העתיקו את id שהוחזר לערך הסביבה הפרטי TASK_ID. אל תלחצו שוב על יצירת משימה רק כדי לבדוק התקדמות.
אחזור המשימה הקיימת
פתחו את הבקשה לאחזור משימה וודאו ש-TASK_ID מכיל את מזהה המשימה שהוחזר. הבקשה הזו משתמשת ב-GET /v1/tasks/:id באותו API. שלחו אותה ידנית, בדקו את תגובת ה-HTTP ואז בדקו את status של המשימה.
| מצב | הפעולה הבאה |
|---|---|
| pending או solving | המשימה עדיין לא הסתיימה. המתינו ואז שלחו שוב את הבקשה לאחזור משימה עם אותו TASK_ID. |
| מוכן | הפסיקו לאחזר. המשימה מכילה פתרון שניתן להשתמש בו. |
| failed | הפסיקו לאחזר. בדקו את errorCode ואת error כדי להחליט מה צריך לשנות. ניתן החזר על פתרונות שנכשלו. |
HTTP 200 או 201 לבדם לא מעידים שפתרון מוכן; רק status: ready מעיד על כך. הבדיקה הידנית הזו בודקת יצירה ואחזור של משימה, ולא אם אתר היעד מקבל את התוצאה.
אם אתם ממשיכים לשליחת טוקן ה-reCAPTCHA ליעד המיועד שלו, השתמשו בזהות הדפדפן userAgent ו-secChUa שהוחזרה ובפרוקסי שהצליח. אל תחליפו כתובות IP ואל תשלבו זהות דפדפן לא קשורה. היעד עדיין עשוי לדחות טוקן מוכן.
אם הבקשה ליצירת משימה חורגת מהזמן הקצוב
חריגה מזמן החיבור הקצוב לא מוכיחה שהיצירה נכשלה. אם יש לכם מזהה משימה, אחזרו אותה. אם לא קיבלתם את המזהה, שלחו שוב את הבקשה ליצירת משימה עם אותו REQUEST_ID ועם נתוני קלט למשימה ללא שינוי. כך משחזרים את המשימה הקיימת במקום ליצור משימה לוגית נוספת.
אל תייצרו REQUEST_ID חדש רק מפני שהתגובה אבדה. שימוש חוזר במזהה עם נתוני קלט שונים למשימה גורם להתנגשות; השתמשו במזהה חדש כשאתם מתחילים משימה חדשה במכוון.
מקורות ותיעוד API
הפעלת המשימה הראשונה שלך.
התחילו עם $5 בקרדיט לסביבת העבודה.