База знания

Продажба на хостинг от 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"}'

Две правила, които струват пари, ако ги сбъркате

  1. Задайте ключ за акаунта на вашия КЛИЕНТ и за сайта на вашата УСЛУГА. Втората поръчка на даден клиент трябва да попадне в акаунта, който той вече има. Ако зададете ключ и за двете на услугата, единият клиент накрая ще има три несвързани акаунта и три отделни панела.
  2. Изпращайте 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/ и го свържете по същия начин.
  • WordPressZinn® Reseller Toolkit: търсене на домени, връзка за вход в хостинга на вашите клиенти и подготовка през WooCommerce, когато дадена поръчка е платена. С отворен код на адрес <https://github.com/Zinn-Digital/zinn-reseller-toolkit> или го изтеглете от Плъгини в таблото си за управление.

6. Стартирайте на живо

Проверете следните неща, преди да приемете реална поръчка:

  • Тестът на връзката е успешен на модула или първото ви извикване на curl връща списък.
  • Ценовата ви листа е зададена (Препродажба → Вашите цени).
  • Вашият шлюз за плащане е свързан (Препродажба → Платежни шлюзове) — вашите клиенти ви плащат през собствения ви акаунт.
  • Данните за вашата компания са въведени (Препродажба → Вашата компания), така че вашите клиентски фактури да носят вашето юридическо лице и ДДС номер, а не нашия.
  • Направили сте една реална поръчка от край до край и сте наблюдавали как сайтът се появява.

Къде се намира всичко останало

Пълната справка за API — всяка крайна точка (endpoint), генерирана от нашата спецификация, с разрешението, от което се нуждае всяка една от тях, е на адрес <https://zinndigital.com/developers/api>.

Все още изпитвате затруднения?

Поддръжката е включена във всеки план с отговори на вашия собствен език.

Свържете се с поддръжката Всички статии