Shisni pritje Zinn® nga HostBill, Blesta ose sistemi juaj

Nëse përdorni WHMCS, përdorni në vend të saj modulin e WHMCS — kjo faqe është për çdo gjë tjetër. Ekzistojnë dy opsione, të dyja falas dhe të dyja me licencë GPL-2.0-or-later.

HostBill

Një modul hostimi me të njëjtat gjashtë veprime si ai i WHMCS.

1. Shkarkojeni atë dhe shpaketojeni.
2. Ngarkoni drejtorinë zinn në includes/modules/Hosting/ në mënyrë që skedarët të vendosen në includes/modules/Hosting/zinn/class.zinn.php dhe includes/modules/Hosting/zinn/ZinnHostBillClient.php.
3. Cilësimet → Modulet → Hostimi, aktivizoni Zinn Digital® dhe shtoni një lidhje:

• Adresa e API-së: https://api.zinndigital.com
• Çelësi i API-së: çelësi juaj i API-së Zinn® (një fushë password, kështu që HostBill e ruan atë të koduar)

1. Te produkti, caktoni Linja e produktit (p.sh. mainstream), Stack (wordpress si parazgjedhje), dhe opsionalisht Aplikacioni dhe Versioni i PHP-së.
2. Shtypni Testo lidhjen.

⛔ Mos e riemërtoni drejtorinë zinn. Ngarkuesi i HostBill nxjerr klasën që kërkon nga emri i drejtorisë, kështu që një riemërtim prodhon një modul që paneli e liston dhe nuk e thërret kurrë.

Çdo gjë tjetër — klienti PHP

Një skedar, pa varësi, pa supozime për panelin. Vendosni ZinnProvisioning.php në bazën tuaj të kodit dhe thirrni gjashtë metoda.

require_once 'ZinnProvisioning.php';

$zinn = new ZinnProvisioning(getenv('ZINN_API_KEY'));

// Kur një porosi paguhet — një herë për ÇDO KLIENT, pastaj një herë për ÇDO SHËRBIM:
$orgId  = $zinn->account('customer-4211', 'Acme Ltd');
$siteId = $zinn->provision('service-9915', $orgId, 'acme.com', 'mainstream', 'wordpress');
// Ruani $orgId për klientin tuaj dhe $siteId për shërbimin tuaj.

$zinn->suspend($siteId, 'INV-2026-114 unpaid');   // një faturë mbetet e papaguar
$zinn->unsuspend($siteId);                        // ata paguajnë
$zinn->terminate($siteId);                        // ata anulojnë — planifikon një fshirje

// Kur klikojnë "hyni në hostimin tim" — gjenerojeni atë në KLIKIM, kurrë në ngarkimin e faqes:
header('Location: ' . $zinn->signInLink($siteId));

Nuk shkruani në PHP? Të njëjtat thirrje gjenden në referencën e API-së dhe mund t'i kryeni ato nga çdo gjë.

Çelësi i API-së

Shtatë leje, dhe asnjë më shumë: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision.

⛔ Jo reseller.manage. Një çelës që ngjitni në një panel faturimi duhet të jetë në gjendje të pezullojë një klient për mospagim dhe t'i identifikojë ata; ai nuk duhet të jetë në gjendje të rishkruajë kredencialet tuaja të portës së pagesave.

Dy rregullat që kushtojnë para kur shkelen

1. Përdorni si çelës të llogarisë KLIENTIN tuaj, dhe të faqes SHËRBIMIN tuaj. Porosia e dytë e një klienti duhet të kalojë në llogarinë që ai tashmë ka. Përdorimi i shërbimit si çelës për të dyja bën që një klient të përfundojë me tre llogari të palidhura dhe tre panele kontrolli të veçanta.
2. Dërgoni një çelës idempotence në çdo krijim, të nxjerrë nga identifikuesi juaj për atë element. Çdo sistem faturimi bën ripërpjekje — një thirrje kthyese e portës së pagesave vjen dy herë, një administrator riekzekuton një përgatitje të dështuar, një klient klikon dy herë. Pa të, përpjekja e dytë krijon një faqe të dytë dhe ju faturoheni për të. Të dy modulet dhe klienti PHP e bëjnë këtë për ju; nëse po thirrni drejtpërdrejt API-në, dërgoni Idempotency-Key.

Tre fusha që harrohen lehtë

Secila prej tyre prish një veprim të tërë dhe asnjëra nuk shfaqet si diçka tjetër përveçse një gabim vlefshmërie — përveç të parës, e cila shfaqet si asgjë fare:

• ⛔⛔ Një klienti duhet t'i caktohet një plan PËRPARA se të mundësohet faqja e tij e parë, me

POST /v1/reseller/clients/{orgId}/plan, dhe subscription_id i tij t'i kalohet POST /v1/sites. Ky është rasti ku nuk ka asnjë gabim për t'u lexuar. Një llogari e re klienti nuk mban asnjë abonim dhe POST /v1/sites nuk ka fushë plani, kështu që një faqe e mundësuar pa një të tillë nuk mbart asnjë plan fare: pasqyra juaj me shumicë ndërtohet nga abonimet aktive të klientëve tuaj, kështu që nuk shtohet asnjë zë dhe Zinn® nuk ju faturon asgjë për sa kohë që hostimi është aktiv; klienti juaj nuk trashëgon kuota, kështu që nuk zbatohet asnjë kuotë në faqen e tij; dhe nuk ka asgjë që një përmirësim të mund të ndryshojë. Porosia kthen 201, faqja mundësohet, dhe funksionon në mënyrë të përsosur. Asgjë në asnjërën anë nuk raporton ndonjë gjë nga këto.

Renditja ka rëndësi: POST /v1/sites regjistron çfarëdo abonimi që ekziston në momentin kur ekzekutohet, kështu që një plan i caktuar më pas nuk lidhet në mënyrë prapavepruese.

• POST /v1/sites kërkon stack_type. Nëse e hiqni, asnjë porosi nuk mund të jetë e suksesshme.
• **DELETE /v1/sites/{siteId} kërkon një trup `{"confirm_domain": "<the site's own

domain>"}** — një konfirmim i shkruar, sepse kjo është folja shkatërruese. Nëse e hiqni, asnjë anulim nuk mund të jetë i suksesshëm, kështu që shërbimi vazhdon të funksionojë dhe ju vazhdoni të faturoheni për të. Lexojeni domenin mbrapsht nga GET /v1/reseller/services/{siteId}` në vend që të përdorni të dhënat tuaja: ai krahasohet me domenin parësor të vetë faqes dhe kurrë me një pseudonim.

Lexoni të gjithë gabimin, jo vetëm fjalinë

Mesazhi i një refuzimi vërtetimi është qëllimisht i përgjithshëm — "The request was well-formed but failed validation." — sepse pjesa e zbatueshme ndodhet në details, e cila emërton fushën dhe arsyen. Të dy modulet dhe klienti PHP ia bashkëngjisin atë mesazhit që i shfaqin administratorit tuaj. Nëse po thërrisni vetë API-n, lexoni error.details; disa zëra mbartin një vlerë të thjeshtë në vend të një fjalie, gjë që shpjegon se si max_sites: 0 arrin tek ju kur plani juaj i rishitësit nuk ka hapësirë.

Përpara porosisë suaj të parë

Faqet që blejnë klientët tuaj zbriten nga kuota e faqeve të planit tuaj të rishitësit, kështu që ju duhet një plan me hapësirë të lirë. Një test lidhjeje nuk mund ta zbulojë këtë — ai lexon programin tuaj dhe nuk mundëson asgjë — kështu që raporton një llogari të rregullt e cila ende nuk mund të shesë. Një porosi e bërë pa një kuotë refuzohet me një mesazh që thotë pikërisht këtë.

Verifikoni shkarkimin tuaj

Të dy arkivat shërbehen përmes TLS nga emri ynë i hostit, kurrë të ridrejtuara diku tjetër, me shumat e tyre kontrolluese SHA-256 të shfaqura pranë lidhjeve të shkarkimit në faqen e shkarkimeve.