თქვენ ახდენთ ჩვენი ჰოსტინგის გადაყიდვას. თქვენი კლიენტები თქვენია: თქვენი ფასები, თქვენი ინვოისები, თქვენი გადახდის პროვაიდერი. აი, როგორ მართოთ ჩვენი პლატფორმა ნებისმიერი სისტემიდან, რომელსაც უკვე იყენებთ — ბილინგის პანელიდან, თქვენი საკუთარი WordPress საიტიდან თუ სკრიპტიდან.
რას ხედავენ სინამდვილეში თქვენი კლიენტები
სანამ ტექნიკურ მხარეზე გადავიდოდეთ: თქვენს კლიენტებს არასოდეს უწევთ ჩვენი დანახვა. არსებობს სამი სამუშაო არეალი და თქვენ ირჩევთ, რომელს გამოიყენებთ.
| სამუშაო არეალი | ვის ეკუთვნის |
|---|
| ჰოსტინგის პანელი, თქვენს საკუთარ ჰოსტის სახელზე | მიუთითეთ პანელის ჰოსტის სახელი განყოფილებაში Reselling → Your brand და თქვენი კლიენტები შევლენ მისამართზე panel.yourcompany.com თქვენი ლოგოთი და თქვენი ფერებით. იგივე პანელი, თქვენი მისამართი. |
| თქვენი საკუთარი ვებსაიტი | WordPress-ის მოდული თქვენს საიტზე განათავსებს დომენის ძიებასა და ერთი დაწკაპებით შესვლის ბმულს, შეკვეთას კი თქვენი საკუთარი WooCommerce-ის გადახდის გვერდის მეშვეობით მიიღებს. |
| თქვენი ბილინგის პანელი | მთავარ შემოსასვლელად რჩება WHMCS ან HostBill; მოდული ახორციელებს რესურსების გამოყოფას მის მიღმა, ხოლო კლიენტის ზონის ღილაკით ისინი პირდაპირ საკუთარ ჰოსტინგში შედიან. |
⛔ რომელსაც არ უნდა აირჩიოთ, თქვენ ხართ ოფიციალური გამყიდველი (merchant of record) თქვენი კლიენტებისთვის: თქვენი ფასები, თქვენი ინვოისები, თქვენი დღგ-ის ნომერი, თქვენი გადახდის პროვაიდერი. ჩვენ ინვოისს გამოვწერთ თქვენზე, თვეში ერთხელ, საბითუმო ფასად.
როდესაც დააყენებთ პანელის ჰოსტის სახელს, შეიყვანეთ ის WordPress-ის მოდულის ველში Panel address და სხვაგან არსად — ამ API-ის მიერ გენერირებული შესვლის ბმულები მას ავტომატურად მიჰყვება.
ოთხი გზა დასაკავშირებლად
არსებობს დაკავშირების ოთხი გზა და ისინი სისტემურად ერთი და იმავე საქმეს აკეთებენ:
| ვისთვის არის |
|---|
| WHMCS-ის მოდული | WHMCS-ის მაღაზიისთვის |
| HostBill-ის მოდული | HostBill-ის მაღაზიისთვის |
| WordPress-ის მოდული | თქვენი საკუთარი WordPress ან WooCommerce საიტიდან გასაყიდად |
| API | ყველაფერი დანარჩენისთვის — Blesta, შიდა სისტემა, cron-ის სკრიპტი |
1. მიიღეთ API გასაღები
თქვენს სამართავ პანელში გადადით განყოფილებაში API keys და შექმენით ის. მიანიჭეთ მხოლოდ ის უფლებები, რაც სჭირდება:
| ნებართვა | რისთვის არის |
|---|
org.read | თქვენი კლიენტების ანგარიშების წაკითხვა |
sites.create | საიტის რესურსების გამოყოფა |
sites.view | სერვისის წაკითხვა |
sites.delete | გაუქმება |
reseller.view | თქვენი სერვისების ჩამონათვალისა და გამოყენების მაჩვენებლების ნახვა |
reseller.provision | შეჩერება, განბლოკვა და კლიენტის სისტემაში შესვლა |
⛔ არ მიანიჭოთ ინტეგრაციას reseller.manage. ეს ნებართვა არედაქტირებს თქვენს ფასთა ნუსხას და თქვენი საკუთარი გადახდის კარიბჭის მონაცემებს. reseller.provision შექმნილია სწორედ იმისთვის, რომ ბილინგის პანელში ან ვებსაიტზე ჩასმულ გასაღებს ეს უფლება არ დასჭირდეს.
გასაღები ნაჩვენებია მხოლოდ ერთხელ. შეინახეთ ის იქ, სადაც ინახავთ თქვენს სხვა ავტორიზაციის მონაცემებს — არასოდეს შეინახოთ ფაილში, რომელსაც თქვენი ვებ-სერვერი გასცემს.
2. განახორციელეთ თქვენი პირველი მოთხოვნა
curl https://api.zinndigital.com/v1/reseller/services \
-H "Authorization: Bearer zdk_live_…"
ეს აბრუნებს თქვენ მიერ გააქტიურებულ ყველა სერვისს, თითო სტრიქონს თითო საიტზე, იმ კლიენტის მითითებით, რომელსაც ის ეკუთვნის, მის სტატუსს და იმას, თუ რამდენს ართმევთ მასში. ახალ ანგარიშზე ეს არის ცარიელი სია — რაც სწორი პასუხია და არა შეცდომა.
3. მთელი ინტეგრაცია, ექვს მოთხოვნაში
როდის მოთხოვნა
შეკვეთა გადახდილია POST /v1/orgs ერთხელ თითო მომხმარებელზე
POST /v1/sites ერთხელ თითო სერვისზე
არ გადაუხდიათ POST /v1/reseller/services/{siteId}/suspend
გადაიხადეს POST /v1/reseller/services/{siteId}/unsuspend
გააუქმეს DELETE /v1/sites/{siteId}
"ჰოსტინგში შესვლა" POST /v1/reseller/services/{siteId}/sso
რესურსების გამოყოფა შედგება ორი მოთხოვნისგან, და იდენტიფიკატორებს გადამწყვეტი მნიშვნელობა აქვს:
# 1. მომხმარებლის ანგარიში — იდენტიფიცირებული თქვენი მომხმარებლის ID-ით
curl -X POST https://api.zinndigital.com/v1/orgs \
-H "Authorization: Bearer zdk_live_…" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: account-4211" \
-d '{"type":"customer","name":"Acme Ltd"}'
# 2. მათი საიტი — იდენტიფიცირებული თქვენი სერვისის ID-ით
curl -X POST https://api.zinndigital.com/v1/sites \
-H "Authorization: Bearer zdk_live_…" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: service-9915" \
-d '{"org_id":"<from step 1>","product_line":"mainstream","primary_domain":"acme.com"}'
ორი წესი, რომელთა დარღვევაც ფინანსურად გაზარალებთ
- დააკავშირეთ ანგარიში თქვენს მომხმარებელთან (CUSTOMER), ხოლო საიტი — თქვენს სერვისთან (SERVICE). მომხმარებლის მეორე შეკვეთა უნდა მოხვდეს იმ ანგარიშზე, რომელიც მას უკვე აქვს. თუ ორივეს სერვისზე დააკავშირებთ, ერთ მომხმარებელს სამი დაუკავშირებელი ანგარიში და სამი ცალკეული პანელი ექნება.
- გაგზავნეთ
Idempotency-Key ყოველ POST მოთხოვნაზე, რომელიც აგებულია ამ ობიექტის თქვენეული ID-ისგან. ყველა ბილინგის სისტემა ახორციელებს განმეორებით მცდელობას — გადახდის კარიბჭის შეტყობინება მოდის ორჯერ, ადმინისტრატორი ხელახლა უშვებს ჩაშლილ აქტივაციას, მომხმარებელი აწკაპებს ორჯერ. გასაღების გარეშე მეორე მცდელობა შექმნის მეორე საიტს და მისთვის თანხა თქვენ ჩამოგეჭრებათ.
სამი პასუხი, რომლებიც არ უნდა გააერთიანოთ ორში
unsuspend მოთხოვნამ შეიძლება დააბრუნოს 409. ეს ნიშნავს, რომ საიტი შეჩერებულია ჩვენი უსაფრთხოების (abuse) გუნდის მიერ და არა თქვენ მიერ. აჩვენეთ შეტყობინება; ნუ გაიმეორებთ მოთხოვნას.
- **გაუქმება ნიშნავს წაშლის დაგეგმვას და არა მის დაუყოვნებლივ შესრულებას.** თარიღი ბრუნდება ველში
pending_deletion_at. მომხმარებლისთვის იმის თქმა, რომ მისი მონაცემები უკვე წაშლილია, მაშინ როცა ეს ასე არ არის, უარესია, ვიდრე არაფრის თქმა.
disk_used_bytes შეიძლება იყოს null, ხოლო null არ ნიშნავს ნულს. ეს ნიშნავს, რომ ჩვენ ვერ შევძელით გაზომვა, და არა იმას, რომ არაფერია გამოყენებული. გამოტოვეთ ის — ნუ ჩაწერთ 0-ს თქვენს ჩანაწერებში, წინააღმდეგ შემთხვევაში მომხმარებელს აჩვენებთ გამოყენების მწვანე ინდიკატორს იმ საიტისთვის, რომლის მონაცემებიც არ გაქვთ.
4. კლიენტის სისტემაში შესვლა
POST /v1/reseller/services/{siteId}/sso აბრუნებს ერთჯერად URL-ს, რომელიც თქვენს კლიენტს პირდაპირ საკუთარ ანგარიშში გადაიყვანს, უკვე ავტორიზებულ მდგომარეობაში.
⛔ დააგენერირეთ ის მაშინ, როცა ისინი აწკაპებენ, და არასოდეს — გვერდის რენდერინგის დროს. ბმული არის ერთჯერადი და ვადა ეწურება რამდენიმე წუთში, ამიტომ გვერდში ჩაწერილი ბმული გაუქმდება გვერდის პირველივე ნახვისას და დარჩება ყველა ქეშში თქვენსა და ბრაუზერს შორის.
5. დააინსტალირეთ მოდული ალტერნატივის სახით
- WHMCS — დააკოპირეთ მოდული მისამართზე
modules/servers/zinn/, დაამატეთ სერვერი, რომლის Password არის თქვენი API გასაღები, და მიუთითეთ პროდუქტის ხაზი პროდუქტზე. დააჭირეთ Test Connection: ის განახორციელებს რეალურ მოთხოვნას და გაცნობებთ პლატფორმის პასუხს.
- HostBill — დააკოპირეთ მისამართზე
includes/modules/Hosting/zinn/ და დააკავშირეთ იმავე გზით.
- WordPress — Zinn® Reseller Toolkit: დომენის ძიება, შესვლის ბმული თქვენი კლიენტების ჰოსტინგში და WooCommerce-ის მეშვეობით რესურსების გამოყოფა შეკვეთის გადახდისთანავე. ღია კოდით ხელმისაწვდომია მისამართზე <https://github.com/Zinn-Digital/zinn-reseller-toolkit>, ან ჩამოტვირთეთ თქვენი სამართავი პანელის განყოფილებიდან Plugins.
6. გაშვება რეალურ რეჟიმში
შეამოწმეთ ეს პუნქტები რეალური შეკვეთის მიღებამდე:
- კავშირის ტესტი წარმატებით სრულდება მოდულში, ან თქვენი პირველი
curl აბრუნებს სიას.
- თქვენი ფასთა ნუსხა განსაზღვრულია (Reselling → Your prices).
- თქვენი გადახდის კარიბჭე დაკავშირებულია (Reselling → Payment gateways) — თქვენი კლიენტები გიხდიან თქვენ, თქვენი საკუთარი ანგარიშის მეშვეობით.
- თქვენი კომპანიის რეკვიზიტები მითითებულია (Reselling → Your company), რათა თქვენი კლიენტის ინვოისებზე დატანილი იყოს თქვენი იურიდიული პირი და დღგ-ის ნომერი, და არა ჩვენი.
- თქვენ განახორციელეთ ერთი რეალური შეკვეთა თავიდან ბოლომდე და ნახეთ საიტის გამოჩენა.
სად მოიძიოთ ყველაფერი დანარჩენი
სრული API დოკუმენტაცია — ყველა ენდპოინტი, გენერირებული ჩვენი სპეციფიკაციიდან, თითოეულისთვის საჭირო ნებართვის მითითებით — ხელმისაწვდომია მისამართზე <https://zinndigital.com/developers/api>.