HostBill, Blesta અથવા તમારી પોતાની સિસ્ટમ પરથી Zinn® હોસ્ટિંગ વેચો

જો તમે WHMCS ચલાવો છો, તો તેના બદલે WHMCS મોડ્યુલનો ઉપયોગ કરો — આ પેજ બાકીની બધી બાબતો માટે છે. બે વિકલ્પો છે, બંને મફત અને બંને GPL-2.0-or-later છે.

HostBill

WHMCS મોડ્યુલ જેવા જ સમાન છ એક્શન્સ ધરાવતું હોસ્ટિંગ મોડ્યુલ.

1. તેને ડાઉનલોડ કરો અને અનઝિપ કરો.
2. zinn ડિરેક્ટરીને includes/modules/Hosting/ માં અપલોડ કરો જેથી ફાઇલો includes/modules/Hosting/zinn/class.zinn.php અને includes/modules/Hosting/zinn/ZinnHostBillClient.php પર પહોંચી જાય.
3. Settings → Modules → Hosting, Zinn Digital® સક્રિય કરો, અને કનેક્શન ઉમેરો:

• API address: https://api.zinndigital.com
• API key: તમારી Zinn® API કી (એક password ફીલ્ડ, જેથી HostBill તેને એન્ક્રિપ્ટેડ સંગ્રહિત કરે છે)

1. પ્રોડક્ટ પર Product line (દા.ત. mainstream), Stack (મૂળભૂત રીતે wordpress), અને વૈકલ્પિક રીતે Application તેમજ PHP version સેટ કરો.
2. Test connection દબાવો.

⛔ zinn ડિરેક્ટરીનું નામ બદલશો નહીં. HostBill નું લોડર ડિરેક્ટરીના નામ પરથી જે ક્લાસ શોધે છે તે મેળવે છે, તેથી નામ બદલવાથી એવું મોડ્યુલ બને છે જેને પેનલ સૂચિબદ્ધ તો કરે છે પણ ક્યારેય કૉલ કરતી નથી.

બીજું કંઈપણ — PHP ક્લાયન્ટ

એક ફાઇલ, કોઈ નિર્ભરતા (dependencies) નહીં, કોઈ પેનલ ધારણાઓ નહીં. ZinnProvisioning.php ને તમારા પોતાના કોડબેઝમાં મૂકો અને છ મેથડ્સને કૉલ કરો.

require_once 'ZinnProvisioning.php';

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

// When an order is paid — once per CUSTOMER, then once per SERVICE:
$orgId  = $zinn->account('customer-4211', 'Acme Ltd');
$siteId = $zinn->provision('service-9915', $orgId, 'acme.com', 'mainstream', 'wordpress');
// Store $orgId against your customer and $siteId against your service.

$zinn->suspend($siteId, 'INV-2026-114 unpaid');   // an invoice goes unpaid
$zinn->unsuspend($siteId);                        // they pay
$zinn->terminate($siteId);                        // they cancel — schedules a deletion

// When they click "log in to my hosting" — mint it on the CLICK, never on page render:
header('Location: ' . $zinn->signInLink($siteId));

PHP નથી લખી રહ્યા? આ જ કૉલ્સ API reference માં છે અને તમે તેને કોઈપણ જગ્યાએથી કરી શકો છો.

API કી

સાત પરવાનગીઓ, અને તેનાથી વધુ નહીં: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision.

⛔ reseller.manage નહીં. બિલિંગ પેનલમાં તમે જે કી પેસ્ટ કરો છો તે નોન-પેમેન્ટ માટે ક્લાયન્ટને રોકી રાખવા અને તેમને સાઇન ઇન કરવા સક્ષમ હોવી જોઈએ; તે તમારા પોતાના પેમેન્ટ-ગેટવે ઓળખપત્રોને ફરીથી લખવા માટે સક્ષમ હોવી જોઈએ નહીં.

બે નિયમો જે તૂટવા પર નાણાકીય નુકસાન થાય છે

1. એકાઉન્ટને તમારા CUSTOMER પર અને સાઇટને તમારા SERVICE પર કી (Key) કરો. ગ્રાહકનો બીજો ઓર્ડર તેમની પાસે પહેલેથી જ હોય તેવા એકાઉન્ટમાં જવો જોઈએ. બંનેને સેવા પર કી કરો અને એક ગ્રાહક ત્રણ અસંબંધિત એકાઉન્ટ્સ અને ત્રણ અલગ કંટ્રોલ પેનલ્સ મેળવી બેસે છે.
2. દરેક બનાવટ પર એક આઇડેમ્પોટન્સી કી મોકલો, જે તે વસ્તુ માટે તમારા પોતાના આઈડી પરથી મેળવેલી હોય. દરેક બિલિંગ સિસ્ટમ પુનઃપ્રયાસ કરે છે — ગેટવે કૉલબેક બે વાર આવે છે, એડમિન નિષ્ફળ પ્રોવિઝનને ફરીથી ચલાવે છે, ગ્રાહક ડબલ-ક્લિક કરે છે. તેના વિના બીજો પ્રયાસ બીજી સાઇટ બનાવે છે અને તેનું બિલ તમને વસૂલવામાં આવે છે. બંને મોડ્યુલ્સ અને PHP ક્લાયન્ટ તમારા માટે આ કરે છે; જો તમે API ને સીધો કૉલ કરી રહ્યાં છો, તો Idempotency-Key મોકલો.

ત્રણ ફીલ્ડ્સ જે સરળતાથી છૂટી જાય છે

દરેક એક આખા ક્રિયાપદ (verb) ને તોડી નાખે છે, અને માન્યતા ભૂલ (validation error) સિવાય કંઈપણ દેખાતું નથી — સિવાય કે પ્રથમ, જે કંઈપણ નહીં તરીકે દેખાય છે:

• ⛔⛔ ગ્રાહકની પ્રથમ સાઇટ પ્રાવિઝન થાય તે પહેલાં તેને પ્લાન પર મૂકવો આવશ્યક છે, આ

POST /v1/reseller/clients/{orgId}/plan સાથે, અને તેનું subscription_id આ POST /v1/sites ને પાસ કરવામાં આવે છે. આ તે છે જેમાં વાંચવા માટે કોઈ ભૂલ નથી. નવું ગ્રાહક એકાઉન્ટ કોઈ સબ્સ્ક્રિપ્શન ધરાવતું નથી અને POST /v1/sites માં કોઈ પ્લાન ફીલ્ડ નથી, તેથી કોઈ પણ વગર પ્રાવિઝન થયેલી સાઇટ પર કોઈ પ્લાન લાગુ થતો નથી: તમારું હોલસેલ સ્ટેટમેન્ટ તમારા ગ્રાહકોના સક્રિય સબ્સ્ક્રિપ્શન્સમાંથી બનાવવામાં આવે છે, તેથી કોઈ લાઇન જનરેટ થતી નથી અને જ્યાં સુધી હોસ્ટિંગ ચાલુ રહે ત્યાં સુધી Zinn® તમારી પાસેથી કંઈપણ ચાર્જ કરતું નથી; તમારા ગ્રાહકને કોઈ એલાઉન્સ વારસામાં મળતું નથી, તેથી તેમની સાઇટ પર કોઈ ક્વોટા લાગુ થતો નથી; અને અપગ્રેડ દ્વારા બદલવા માટે કંઈપણ હોતું નથી. ઓર્ડર 201 પરત કરે છે, સાઇટ પ્રાવિઝન થાય છે, અને તે સંપૂર્ણ રીતે સેવા આપે છે. બંનેમાંથી કોઈ પણ છેડો આ વિશે કંઈપણ રિપોર્ટ કરતું નથી.

ક્રમ મહત્વપૂર્ણ છે: POST /v1/sites જે ક્ષણે ચાલે છે તે ક્ષણે જે પણ સબ્સ્ક્રિપ્શન મોજૂદ હોય તેને રેકોર્ડ કરે છે, તેથી ત્યાર પછી સેટ કરેલો પ્લાન પાછલી અસરથી લાગુ થતો નથી.

• POST /v1/sites માટે stack_type જરૂરી છે. તેને બાદ કરો અને કોઈ ઓર્ડર સફળ થઈ શકશે નહીં.
• **DELETE /v1/sites/{siteId} માટે `{"confirm_domain": "<the site's own

domain>"} ની બોડી જરૂરી છે** — એક ટાઇપ કરેલી પુષ્ટિ, કારણ કે આ વિનાશક ક્રિયા છે. તેને બાદ કરો અને કોઈ રદ કરવાની પ્રક્રિયા સફળ થઈ શકશે નહીં, તેથી સેવા ચાલુ રહેશે અને તેના માટે તમારું બિલિંગ ચાલુ રહેશે. તમારા પોતાના રેકોર્ડનો ઉપયોગ કરવાને બદલે GET /v1/reseller/services/{siteId}` માંથી ડોમેન પાછું વાંચો: તેની સરખામણી સાઇટના પોતાના પ્રાથમિક ડોમેન સામે થાય છે અને ક્યારેય ઉપનામ (એલિયાસ) સામે થતી નથી.

માત્ર વાક્ય જ નહીં, પરંતુ સમગ્ર ભૂલ વાંચો

માન્યતા અસ્વીકારનો સંદેશ જાણીજોઈને સામાન્ય રાખવામાં આવ્યો છે — "The request was well-formed but failed validation." — કારણ કે પગલાં લઈ શકાય તેવો અડધો ભાગ details માં છે, જે ફીલ્ડ અને તેનું કારણ દર્શાવે છે. મોડ્યુલ્સ અને PHP ક્લાયન્ટ બંને તેને તમારા એડમિનને બતાવવામાં આવતા સંદેશમાં જોડે છે. જો તમે જાતે API ને કૉલ કરી રહ્યા છો, તો error.details વાંચો; કેટલીક એન્ટ્રીઓ વાક્યને બદલે માત્ર એક મૂલ્ય ધરાવે છે, જે રીતે તમારા પુનઃવિક્રેતા (રીસેલર) પ્લાનમાં જગ્યા ન હોય ત્યારે max_sites: 0 તમારા સુધી પહોંચે છે.

તમારા પ્રથમ ઓર્ડર પહેલાં

તમારા ગ્રાહકો જે સાઇટ્સ ખરીદે છે તે તમારા રીસેલર પ્લાનના સાઇટ એલાઉન્સ સામે ગણાય છે, તેથી તમારે એવી યોજનાની જરૂર છે જેમાં જગ્યા ઉપલબ્ધ હોય. કનેક્શન ટેસ્ટ આને શોધી શકતો નથી — તે તમારા પ્રોગ્રામને વાંચે છે અને કંઈપણ પ્રાવિઝન કરતું નથી — તેથી તે એક સ્વસ્થ એકાઉન્ટની જાણ કરે છે જે હજુ સુધી વેચી શકતું નથી. એલાઉન્સ વિના મૂકવામાં આવેલ ઓર્ડર બરાબર તે જ દર્શાવતા સંદેશ સાથે નકારવામાં આવે છે.

તમારું ડાઉનલોડ ચકાસો

બંને આર્કાઇવ્સ અમારા પોતાના હોસ્ટનેમ પરથી TLS દ્વારા સેવા અપાય છે, ક્યારેય અન્યત્ર રીડાયરેક્ટ થતા નથી, અને તેમના SHA-256 ચેકસમ ડાઉનલોડ્સ પેજ પર ડાઉનલોડ લિંક્સની બાજુમાં છાપવામાં આવ્યા છે.