ამ გვერდზე

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

დეველოპერები

API დოკუმენტაცია

RE:HOST-ის ავტომატიზაციის API — სააგენტოებისა და დეველოპერებისთვის, რომლებიც სერვისებს პროგრამულად მართავენ.

API ტოკენის მიღება OpenAPI სპეციფიკაციის ჩამოტვირთვა

მორგებულია AI კოდირების აგენტებზეც

გადაეცით ამ გვერდის ლინკი AI კოდირების ასისტენტს — Claude Code, Codex, GitHub Copilot ან მსგავსს — და სთხოვეთ, ინტეგრირება გაუკეთოს RE:HOST-ის API-ს თქვენს პროექტში. ეს არის უბრალო, სერვერზე დარენდერებული HTML, ასე რომ აგენტს შეუძლია პირდაპირ წაიკითხოს, ანგარიშის გარეშეც.

http://v2.rehost.ge/api-docs

როგორ დავიწყოთ

შექმენით უფასო RE:HOST ანგარიში.

შექმენით API ტოკენი თქვენი პანელიდან, ზუსტად საჭირო წვდომით.

გამოიყენეთ ის bearer ტოკენად API-ის გამოძახებისას — დაიწყეთ ქვემოთ მოცემული მაგალითით.

უკვე გაქვთ ანგარიში? შესვლა

ავთენტიფიკაცია

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

curl https://my.rehost.ge/api/v1/services \ -H "Authorization: Bearer <your-token>" \ -H "Accept: application/json"

ყველა მოთხოვნისა და პასუხის სხეული არის JSON ფორმატში. ყველა endpoint-ი მდებარეობს /api/v1 პრეფიქსის ქვეშ.

შესაძლებლობები

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

შესაძლებლობა	იძლევა წვდომას
`view`	სერვისების, პაკეტებისა და მიგრაციის მოთხოვნების სია და ნახვა
`technical`	სერვისების შექმნა, დომენების რეგისტრაცია, სერვისის შეჩერება/აღდგენა/პაროლის განულება/SSO შესვლა, სერვისის წვდომების მართვა, ვებჰუკების მართვა, მიგრაციის მოთხოვნების შექმნა
`billing`	ინვოისების სია და ნახვა, Manage-ტრეკის კლიენტის ანგარიშების შექმნა

ტოკენი ასევე შეიძლება შეიზღუდოს კონკრეტულ სერვისებზე შექმნისას — თუ შეიზღუდა, ყოველი მოთხოვნა დამატებით მოწმდება ამ სიის მიხედვით.

მოთხოვნების ლიმიტი და შეცდომები

60 მოთხოვნა წუთში, თითოეულ ტოკენზე. ლიმიტს გადაჭარბებული მოთხოვნა აბრუნებს 429 Too Many Requests.

ავტორიზაციის შეცდომა (აკლია შესაძლებლობა, არასწორი ანგარიში, დაუშვებელი სერვისი) აბრუნებს 403 უბრალო ტექსტური message ველს, რომელიც განმარტავს რომელი შემოწმება ჩავარდა. ვალიდაციის შეცდომა აბრუნებს 422 Laravel-ის სტანდარტული {"message": "...", "errors": {...}} ფორმატით.

იდემპოტენტურობა

სერვისის შექმნის ყოველი მოთხოვნა უნდა შეიცავდეს Idempotency-Key ჰედერს — კლიენტის მიერ გენერირებულ უნიკალურ მნიშვნელობას (UUID შესაფერისია). იგივე გასაღებით მოთხოვნის გამეორება აბრუნებს თავდაპირველ პასუხს ახალი სერვისის შექმნის ნაცვლად; იგივე გასაღებით პარალელური მოთხოვნა, სანამ პირველი მუშავდება, იღებს 409 Conflict. ჰედერის საერთოდ არარსებობისას აბრუნებს 400.

გვერდები

ქვემოთ მოცემული ყველა სია-endpoint გვერდებადაა დაყოფილი.

გამოიყენეთ ?page= გვერდებს შორის გადასაადგილებლად და ?per_page= გვერდის ზომის დასაყენებლად (ნაგულისხმევი 25 — პაკეტებისთვის 50 — მაქსიმუმ 100).

ყოველი სიის პასუხი გახვეულია იმავე სტრუქტურაში:

{ "data": [ /* ... */ ], "meta": { "current_page": 1, "per_page": 25, "total": 63, "last_page": 3 } }

Endpoint-ები

პაკეტები

GET /api/v1/plans view

აჩვენებს ყველა შესაძენ პაკეტს — ეს არის plan_id მნიშვნელობები, რომლებსაც POST /api/v1/services იღებს. Manage-ტრეკის კლიენტის ანგარიშს ასევე უჩანს manage_discount_percent და price_after_discount თითოეული პაკეტისთვის — ეს არის ფასი, რომელსაც ეს ტოკენის ანგარიში რეალურად იხდის.

სერვისები

GET /api/v1/services view

აჩვენებს ტოკენის ანგარიშის ყველა სერვისს (ან, თუ შეზღუდულია — მხოლოდ შეზღუდულ სერვისებს).

GET /api/v1/services/{id} view

აბრუნებს ერთ სერვისს.

{ "data": { "id": 42, "plan": "VIP", "product_type": "shared_hosting", "status": "active", "domain": "example.ge", "billing_cycle": "monthly", "currency": "GEL", "price": 2499, "next_due_date": "2026-10-01", "provisioning_status": "provisioned", "created_at": "2026-08-01T10:00:00+00:00" } }

POST /api/v1/services technical

შეუკვეთეთ ახალი სერვისი. საჭიროებს Idempotency-Key ჰედერს, აღწერილს ზემოთ. ინვოისი გენერირდება მაშინვე; სერვისი აქტივირდება გადახდისთანავე, ისევე როგორც პანელში გაფორმებული შეკვეთის შემთხვევაში.

ველი	ტიპი	შენიშვნები
`plan_id`	integer	სავალდებულო — აქტიური პაკეტი აქტიურ პროდუქტზე
`currency`	string	სავალდებულო — GEL, USD ან EUR
`domain`	string	სავალდებულოა ჰოსტინგის პაკეტებისთვის, სხვა შემთხვევაში არ გამოიყენება

პასუხი შეიცავს invoice ობიექტს — მისი total არის ის, რაც ამ შეკვეთაზე რეალურად დაერიცხა, Manage-ტრეკის ფასდაკლების გამოკლებით; ხოლო შეკვეთის საკუთარი price ველი ყოველთვის არის ფასდაუკლებელი საცალო ფასი.

POST /api/v1/services/{id}/suspend technical

POST /api/v1/services/{id}/unsuspend technical

რიგში აყენებს შეჩერებას/აღდგენას — იმავე თავიდან-ცდის job-ს, რომელსაც ადმინ პანელიც უშვებს.

POST /api/v1/services/{id}/password technical

ცვლის საკონტროლო პანელის პაროლს. ღრუბლოვანი/WordPress ჰოსტინგისთვის გადაეცით password ველი (მინ. 8 სიმბოლო). Root VPS-ისთვის ან ვირტუალური დესკტოპისთვის სხეული საჭირო არ არის — პაროლი გენერირდება და ერთხელ ბრუნდება პასუხში, რადგან ეს მისი გაგების ერთადერთი საშუალებაა.

GET /api/v1/services/{id}/cpanel-sso technical

აბრუნებს cPanel-ში ერთჯერადი შესვლის (SSO) url.

GET /api/v1/services/{id}/grants technical

POST /api/v1/services/{id}/grants technical

DELETE /api/v1/services/{id}/grants/{grantId} technical

უზიარებს (ან უუქმებს წვდომას) ერთ სერვისს სხვა RE:HOST მომხმარებელს ელფოსტით — { "email": "...", "permission": "view|manage", "expires_at": "..." }.

ინვოისები

GET /api/v1/invoices billing

აჩვენებს ტოკენის ანგარიშის ყველა ინვოისს.

GET /api/v1/invoices/{id} billing

აბრუნებს ერთ ინვოისს.

{ "data": { "id": 91, "invoice_number": "REHOST-2026-00091", "status": "paid", "currency": "GEL", "subtotal": 2499, "total": 2499, "due_date": "2026-09-08", "paid_at": "2026-09-05T14:22:00+00:00", "order_id": 42 } }

ვებჰუკის გამოწერები

GET /api/v1/webhooks technical

აჩვენებს ანგარიშის ვებჰუკის გამოწერებს.

POST /api/v1/webhooks technical

არეგისტრირებს ვებჰუკს. პასუხი შეიცავს ხელმოწერის secret მხოლოდ ერთხელ — შეინახეთ დაუყოვნებლივ, იგივე წესი რაც თავად ტოკენს ეხება.

ველი	ტიპი	შენიშვნები
`url`	string	სავალდებულო — უნდა იყოს ვალიდური URL
`events`	array	სავალდებულო — ერთი ან რამდენიმე ქვემოთ მოცემული მოვლენის სახელი

DELETE /api/v1/webhooks/{id} technical

შლის ვებჰუკის გამოწერას.

დომენები

GET /api/v1/domains/check view

POST /api/v1/domains/check view

ამოწმებს ერთი ან რამდენიმე დომენის ხელმისაწვდომობას.

POST /api/v1/domains technical

არეგისტრირებს დომენს — იმავე შეკვეთის პროცესით, რასაც პანელი იყენებს, ამიტომ ფასი და გააქტიურება იდენტურია. საჭიროებს domain, years, currency, nameserver_mode და registrant_contact. ინვოისი გენერირდება მაშინვე, ისევე როგორც სერვისის შექმნისას.

ანგარიშები

GET /api/v1/accounts view

POST /api/v1/accounts billing

მხოლოდ Manage-ტრეკისთვის: აჩვენებს ან ქმნის ამ სააგენტოს კუთვნილ კლიენტის ანგარიშს (მოითხოვს Growth პარტნიორის დონეს ან უფრო მაღალს). საჭიროებს name; company_name, company_number, vat_number და currency არასავალდებულოა.

მიგრაციის მოთხოვნები

GET /api/v1/migration-requests view

POST /api/v1/migration-requests technical

GET /api/v1/migration-requests/{id} view

რიგში აყენებს საიტის მიგრაციის მოთხოვნას დომენისთვის — საჭიროებს domain; სურვილისამებრ, აკავშირებს მას order_id და იმავე მოთხოვნაში აყენებს წყაროს ტიპისა და მოცულობის კითხვებს. მიგრაციის მონაცემების ატვირთვა და საბოლოო გაგზავნა შესაძლებელია მხოლოდ პანელიდან.

ვებჰუკები

გამოწერილი მოვლენები იგზავნება HTTP POST მოთხოვნით თქვენს რეგისტრირებულ URL-ზე მაშინვე, როცა ხდება — ასე რომ შეგიძლიათ რეაგირება და არა გამუდმებით შემოწმება.

მოვლენა	ეშვება, როცა
`service.provisioned`	სერვისის პროვიჟენინგი მთავრდება.
`invoice.paid`	ინვოისი მონიშნულია გადახდილად.
`service.suspended`	სერვისი ჩერდება.
`invoice.created`	სერვისისთვის გენერირდება ახალი ინვოისი (განახლების ჩათვლით).
`service.expiring`	სერვისი შედის განახლების შეტყობინების პერიოდში.
`service.terminated`	სერვისი წყდება.
`service.transfer_accepted`	სერვისის მფლობელობის გადაცემა დადასტურებულია — იგზავნება როგორც გადამცემ, ისე მიმღებ ანგარიშზე.

მონაცემები (Payload)

{ "event": "invoice.paid", "data": { "...": "..." }, "timestamp": "2026-08-30T13:00:00+00:00" }

ხელმოწერის შემოწმება

ყოველი მიწოდება შეიცავს X-RehostGe-Signature ჰედერს — ზუსტი მოთხოვნის სხეულის HMAC-SHA256 ჰეშს, თქვენი ვებჰუკის საკუთარი საიდუმლოთი დაშიფრულს. თავად გამოთვალეთ და შეადარეთ, სანამ მონაცემებს ენდობით.

$expected = hash_hmac('sha256', $rawRequestBody, $webhookSecret); if (!hash_equals($expected, $request->header('X-RehostGe-Signature'))) { abort(401); }

მიწოდება, რომელიც წარმატებულ (2xx) პასუხს არ იღებს, თავიდან იცდება 3-ჯერ ზრდადი შუალედით, შემდეგ წყდება.

ვერსიები

ყოველი endpoint მდებარეობს /api/v1-ის ქვეშ. უკუთავსებადი ცვლილებები — ახალი ველები, ახალი არასავალდებულო პარამეტრები, ახალი endpoint-ები — გამოიცემა ვერსიის ცვლილების გარეშე.

დამრღვევი (breaking) ცვლილება გამოვა ახალი /api/v2 პრეფიქსით, ხოლო /v1 გაგრძელდება წინასწარ გამოცხადებული პერიოდის განმავლობაში — არასდროს მოიხსნება გაფრთხილების გარეშე.

ცვლილებების ისტორია

თარიღი	რა შეიცვალა
`2026-09-20`	გამოქვეყნდა ამ API-ის მანქანურად წაკითხვადი OpenAPI 3.0 სპეციფიკაცია — იხილეთ ზემოთ ბმული „OpenAPI სპეციფიკაციის ჩამოტვირთვა“.
`2026-09-20`	ყველა სია-endpoint-ს დაემატა გვერდებად დაყოფა (page/per_page პარამეტრები). დოკუმენტაციის გვერდი გახდა საჯაროდ ხელმისაწვდომი.
`v1`	საწყისი ვერსია: services, invoices, plans, webhooks, domains, accounts, migration-requests.