База знания
Продажба на хостинг от Zinn® през собствените ви системи
Управлявайте хостинга на Zinn от собствения си панел за фактуриране, WordPress сайт или скриптове: вземете API ключ, направете първото си извикване и шестте извиквания, от които се състои цялата интеграция.
Ви препродавате нашия хостинг. Вашите клиенти си остават вашите: вашите цени, вашите фактури, вашият доставчик на плащания. Ето как управлявате нашата платформа от каквото вече използвате — панел за биринг, вашият собствен WordPress сайт или скрипт.
Какво всъщност виждат вашите клиенти
Преди техническите детайли: вашите клиенти никога не трябва да ни виждат. Три интерфейса и вие избирате кой да използвате.
| Интерфейс | Чия собственост е | |---|---| | Хостинг панелът, на собствения ви хостинг домейн | Задайте хостинг домейн на панела в Препродажба → Вашият бранд и вашите клиенти ще влизат в panel.yourcompany.com с вашето лого и вашите цветове. Същият панел, вашият адрес. | | Вашият собствен уебсайт | Приставката за WordPress добавя търсене на домени и връзка за вход с едно кликване на вашия сайт и обработва поръчката през собствената ви каса на WooCommerce. | | Вашият биринг панел | WHMCS или HostBill остава главният вход; модулът извършва подготовката зад него, а бутонът в клиентската зона ги взима направо в техния хостинг. |
⛔ Каквото и да изберете, вие сте търговецът по записите за вашите клиенти: вашите цени, вашите фактури, вашият ДДС номер, вашият доставчик на плащания. Ние фактурираме вас, веднъж месечно, на едро.
След като зададете хостинг домейн на панела, го въведете в полето Адрес на панела на приставката за WordPress и в нищо друго — връзките за вход, които този API генерира, го следват автоматично.
Четирите начина за достъп
Има четири начина за достъп и всички те правят едно и също отзад:
| | За | |---|---| | Модулът за WHMCS | Магазин в WHMCS | | Модулът за HostBill | Магазин в HostBill | | Приставката за WordPress | Продажби от собствения ви сайт на WordPress или WooCommerce | | API | Всичко останало — Blesta, вътрешна система, cron скрипт |
1. Вземете API ключ
В таблото си за управление отидете на API ключове и създайте един. Дайте му само това, от което се нуждае:
| Разрешение | Защо | |---|---| | 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"}'
Две правила, които струват пари, ако ги сбъркате
- Задайте ключ за акаунта на вашия КЛИЕНТ и за сайта на вашата УСЛУГА. Втората поръчка на даден клиент трябва да попадне в акаунта, който той вече има. Ако зададете ключ и за двете на услугата, единият клиент накрая ще има три несвързани акаунта и три отделни панела.
- Изпращайте
Idempotency-Keyпри всяко извикване наPOST, изградено от собствения ви идентификатор за съответния обект. Всяка биринг система прави опити повторно — обратният извикване на шлюза пристига два пъти, администратор пуска отново неуспешна подготовка, клиент щраква двукратно. Без ключа вторият опит създава втори сайт и вие сте таксувани за него.
Три отговора, които не трябва да свеждате до два
unsuspendможе да отговори с409. Това означава, че нашият екип за злоупотреби задържа сайта, а не вие. Покажете съобщението; не го опитвайте отново.- **Прекратяването планира изтриване, а не го изпълнява.** Датата се връща като
pending_deletion_at. Да кажете на клиента, че данните му вече ги няма, когато това не е така, е по-лошо, отколкото да не му кажете нищо. disk_used_bytesможе да бъдеnull, а null не е нула. Това означава, че не сме могли да измерим, а не че нищо не е било използвано. Пропуснете го — не пишете0в собствените си записи, или ще покажете на клиента зелена лента за използване за сайт, от който нямате отчитане.
4. Влезте в акаунт на клиент
POST /v1/reseller/services/{siteId}/sso връща URL адрес за еднократна употреба, който отвежда клиента ви директно в собствения му акаунт, като той вече е влязъл.
⛔ Генерирайте го при кликване, никога при визуализиране на страницата. Връзката е за еднократна употреба и изтича за минути, така че връзка, записана в страницата, се изразходва при първото преглеждане на страницата и остава във всеки кеш между вас и браузъра.
5. Инсталирайте модул вместо това
- WHMCS — копирайте модула в
modules/servers/zinn/, добавете сървър, чиято парола е вашият API ключ, и задайте продуктовата линия на продукта. Натиснете Тестване на връзката: тя прави реално обаждане и ви казва какво е казала платформата. - HostBill — копирайте в
includes/modules/Hosting/zinn/и го свържете по същия начин. - WordPress — Zinn® Reseller Toolkit: търсене на домени, връзка за вход в хостинга на вашите клиенти и подготовка през WooCommerce, когато дадена поръчка е платена. С отворен код на адрес <https://github.com/Zinn-Digital/zinn-reseller-toolkit> или го изтеглете от Плъгини в таблото си за управление.
6. Стартирайте на живо
Проверете следните неща, преди да приемете реална поръчка:
- Тестът на връзката е успешен на модула или първото ви извикване на
curlвръща списък. - Ценовата ви листа е зададена (Препродажба → Вашите цени).
- Вашият шлюз за плащане е свързан (Препродажба → Платежни шлюзове) — вашите клиенти ви плащат през собствения ви акаунт.
- Данните за вашата компания са въведени (Препродажба → Вашата компания), така че вашите клиентски фактури да носят вашето юридическо лице и ДДС номер, а не нашия.
- Направили сте една реална поръчка от край до край и сте наблюдавали как сайтът се появява.
Къде се намира всичко останало
Пълната справка за API — всяка крайна точка (endpoint), генерирана от нашата спецификация, с разрешението, от което се нуждае всяка една от тях, е на адрес <https://zinndigital.com/developers/api>.
Все още изпитвате затруднения?
Поддръжката е включена във всеки план с отговори на вашия собствен език.
Свържете се с поддръжката → Всички статии →