შენი VPS-გადამყიდველის ბიზნესის ავტომატიზაცია API-სა და MCP-ს მეშვეობით

Sep 5, 2026 · 2 წთ კითხვა · EQVPS Team

ხელით წარმართული გადამყიდველის ბიზნესი სწრაფად ეჯახება ჭერს: ყოველი შეკვეთა, ყოველი შეჩერება, ყოველი განახლება არის ადამიანი, რომელიც დაფაზე კლიკავს, და შენი დრო კლიენტების რაოდენობასთან ერთად იზრდება. ამ ჭერის გადალახვის გზა ოპერაციის როგორც კოდის წარმართვაა — და EQVPS ხსნის გადამყიდველის მხარეს როგორც REST API-ით, ისე MCP-endpoint-ით, ამიტომ შეგიძლია მისი სკრიპტირება ან AI-აგენტისთვის გადაცემა.

ერთი ტოკენი, 30 გადამყიდველის ხელსაწყო

Partners კაბინეტში იღებ გადამყიდველის ტოკენს (rk_…) და აგზავნი როგორც Authorization: Bearer rk_…. ტოკენი გაფილტრულია როლით: ის ხსნის 30 reseller_* ხელსაწყოს იმავე MCP-endpoint-ზე, რომლებიც ფარავს კლიენტის მთელ სასიცოცხლო ციკლს:

გეგმის შექმნა და მისი ფასის დაყენება,
კლიენტის დამატება,
reseller_order_for_client — შენი ბრენდით VM-ის შეკვეთა,
მისი სტატუსის წაკითხვა,
reseller_suspend_client / reseller_unsuspend_client — შეჩერება და აღდგენა,
განახლება და გაუქმება.

სერვერის შეკვეთა წყვეტს დაფის სესია იყოს და ხდება ერთი ავთენტიფიცირებული გამოძახება.

API თუ MCP — იგივე შესაძლებლობები, ორი კარი

ესენი კონკურენტი ვარიანტები არაა; ესენი ორი შესასვლელია იმავე ხელსაწყოებისკენ:

REST API — ის, რასაც შენი ბექენდიდან ან ბილინგიდან სკრიპტავ. ირთვება გადახდის webhook, შენი კოდი უხმობს შეკვეთის endpoint-ს, VM მზადდება შენი ბრენდით.
MCP-endpoint — იგივე reseller_* ხელსაწყოები ხსნილი AI-აგენტისთვის ან MCP-თავსებადი კლიენტისთვის, ისე რომ მოდელი მათ პირდაპირ მართავს.

გადამყიდველთა უმეტესობა ორივეს იყენებს: ბილინგის webhook, რომელიც REST-ით ამზადებს, და აგენტი, რომელიც უფრო რთულ გადაწყვეტილებებს MCP-ით იღებს.

თხრილი: აგენტი, რომელიც ოპერაციას წარმართავს

სწორედ აქ წყვეტს ის სხვა ნებისმიერ გადამყიდველის პროგრამას ჰგავდეს. რადგან გადამყიდველის ხელსაწყოები MCP-ზეა, შენი rk_ ტოკენით ავთენტიფიცირებულ AI-აგენტს შეუძლია ბიზნესი პირდაპირ წარმართოს — შეუკვეთოს VM, როცა კლიენტი იხდის, წაიკითხოს სტატუსი, შეაჩეროს გადაუხდელობისას, მოხსნას შეჩერება გადახდისას — ციკლში ადამიანის გარეშე. იგივე პლატფორმა, სადაც აგენტს შეუძლია იყიდოს და გაუშვას საკუთარი სერვერი, აგენტს აძლევს საშუალებას წარმართოს ფლოტი შენი კლიენტების სახელით. შენ ადგენ პოლიტიკას; აგენტი ასრულებს მას. ეს არის AI-ის მიერ წარმართული ჰოსტინგის ბიზნესი როგორც კონკრეტული შაბლონი.

მინიმალური ნაკადი

// ავთენტიფიცირდი ყოველი გამოძახება შენი გადამყიდველის ტოკენით
// Authorization: Bearer rk_...

reseller_order_for_client({ client_id, product: "small", os_id: 1 })  // მომზადება შენი ბრენდით
// → service_id, ip, წვდომა — გადაეცი კლიენტს როგორც შენი
reseller_suspend_client({ service_id })       // გადაუხდელობისას
reseller_unsuspend_client({ service_id })      // გადახდისას

ოთხი გამოძახება ცვლის იმას, რაც ადრე იყო დაფის სესია თითო კლიენტზე, თითო მოვლენაზე.

პატიოსანი მასშტაბი

ტოკენი credential-ია. rk_… შენი მთელი კლიენტის ფლოტის გასაღებია — შეინახე როგორც გასაღები და დააროტირე გამჟღავნებისას.
ავტომატიზაცია ასრულებს შენს პოლიტიკას, არა საკუთარს. აგენტი, რომელიც უკვეთავს და აჩერებს, მხოლოდ ისეთი კარგია, როგორც წესები, რომლებიც მას მიეცი; ხარჯვა შეზღუდე წინასწარ გადახდილი ბალანსით, რომ ბაგმა ან ცუდმა მოთხოვნამ არ გაქცეს.
მხარდაჭერა და ბილინგი კვლავ შენია. ავტომატიზაცია აშორებს კლიკს, არა კლიენტთან ურთიერთობას.

საით შემდეგ

სრული ცნობარი — ავთენტიფიკაცია, reseller_* ხელსაწყოები, os_id-ის მართვა და სტატუსები — reseller API / MCP დოკუმენტაციაშია. ახალი ხარ ბიზნეს-მხარეზე? დაიწყე როგორ დავიწყოთ VPS-ის გადამყიდველის ბიზნესი-თი. საბითუმო მხარე white-label გადამყიდველის პროგრამაა.

ხდკ

როგორ მოვახდინო მომზადების ავტომატიზაცია გადამყიდველად?

Partners კაბინეტში იღებ გადამყიდველის ტოკენს (rk_…) და მისით უხმობ იმავე MCP-endpoint-ს (ან REST API-ს). ტოკენი გაფილტრულია როლით: ის ხსნის 30 reseller_* ხელსაწყოს, რომლებიც ფარავს კლიენტის მთელ სასიცოცხლო ციკლს — გეგმის შექმნა, კლიენტის დამატება, მისთვის VM-ის შეკვეთა, სტატუსის წაკითხვა, შეჩერება, შეჩერების მოხსნა, განახლება, გაუქმება. კლიენტისთვის სერვერის შეკვეთა ხდება ერთი ავთენტიფიცირებული გამოძახება დაფის სესიის ნაცვლად.

რა განსხვავებაა API-სა და MCP-ს შორის აქ?

იგივე შესაძლებლობები, ორი კარი. REST API ის არის, რასაც შენი ბექენდიდან ან ბილინგიდან სკრიპტავ. MCP-endpoint ხსნის იმავე reseller_* ხელსაწყოებს AI-აგენტისთვის ან MCP-თავსებადი კლიენტისთვის, ისე რომ მოდელს შეუძლია მათი პირდაპირ მართვა. შეგიძლია ერთი ან ორივე გამოიყენო — ბილინგის webhook, რომელიც REST-ით ამზადებს, და აგენტი, რომელიც დანარჩენს MCP-ით აკეთებს.

შეუძლია თუ არა AI-აგენტს რეალურად აწარმოოს შეკვეთა და შეჩერება?

დიახ — MCP-ზედაპირი სწორედ ამისთვისაა. რადგან გადამყიდველის ხელსაწყოები MCP-ს ხსნილია, შენი rk_ ტოკენით ავთენტიფიცირებულ აგენტს შეუძლია შეუკვეთოს VM, როცა კლიენტი იხდის, წაიკითხოს მისი სტატუსი, შეაჩეროს გადაუხდელობისას და მოხსნას შეჩერება გადახდისას, ყველაფერი დაფაზე მკლიკავი ადამიანის გარეშე. შენ ადგენ პოლიტიკას; აგენტი ასრულებს მას.

როგორ ხდება ჩემი გადამყიდველის წვდომის ავთენტიფიკაცია და შემოსაზღვრა?

გადამყიდველის ტოკენით (rk_…), გაგზავნილი როგორც Authorization: Bearer rk_… . ის გაფილტრულია როლით მხოლოდ reseller_* ხელსაწყოებზე, ამიტომ ის მართავს შენს კლიენტებსა და შენს გეგმებს, არა პლატფორმას მთლიანად. ტოკენი საიდუმლოდ შეინახე ისე, როგორც ნებისმიერი credential; ის შენი მთელი კლიენტის ფლოტის გასაღებია.

აუცილებელია თუ არა ყველაფრის ერთდროულად ავტომატიზაცია?

არა. დაიწყე დაფიდან მომზადებით, შემდეგ ზრდასთან ერთად ყველაზე ხშირი მოქმედებები API-ზე გადაიტანე — ჩვეულებრივ ჯერ შეკვეთა-გადახდისას და შეჩერება-გადაუხდელობისას. აზრი ის არის, რომ საოპერაციო ძალისხმევა წყვეტს კლიენტების რაოდენობასთან მასშტაბირებას, როგორც კი ეს ორი ავტომატიზდება, და სწორედ ეს ხდის დიდ გადამყიდველის წიგნს მომგებიანს.

კომენტარები

ჯერ არ არის კომენტარები. იყავით პირველი.