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 کلائنٹ

ایک فائل، کوئی انحصارات نہیں، پینل سے متعلق کوئی مفروضات نہیں۔ بس 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 ریفرنس میں موجود ہیں اور آپ انہیں کسی بھی چیز سے کر سکتے ہیں۔

API کلید

سات اجازتیں، اور اس سے زیادہ کچھ نہیں: org.create، org.read، sites.create، sites.view، sites.delete، reseller.view، reseller.provision۔

⛔ reseller.manage نہیں۔ وہ کلید جو آپ بلنگ پینل میں پیسٹ کرتے ہیں اسے ادائیگی نہ کرنے پر کلائنٹ کو معطل کرنے اور لاگ ان کرانے کے قابل ہونا چاہیے؛ اسے آپ کے اپنے پیمنٹ گیٹ وے کی اسناد کو دوبارہ لکھنے کے قابل نہیں ہونا چاہیے۔

دو اصول جن کی خلاف ورزی مالی نقصان کا باعث بنتی ہے

1. اکاؤنٹ کو اپنے CUSTOMER کے ساتھ، اور سائٹ کو اپنی SERVICE کے ساتھ منسلک کریں۔ گاہک کا دوسرا آرڈر اسی اکاؤنٹ میں جانا چاہیے جو اس کے پاس پہلے سے موجود ہے۔ دونوں کو سروس سے منسلک کرنے کا نتیجہ یہ نکلے گا کہ ایک ہی گاہک کے پاس تین غیر متعلقہ اکاؤنٹس اور تین الگ الگ کنٹرول پینلز ہو جائیں گے۔
2. ہر تخلیق پر ایک idempotency کلید بھیجیں، جو اس چیز کے لیے آپ کی اپنی شناختی آئی ڈی سے اخذ کی گئی ہو۔ ہر بلنگ سسٹم دوبارہ کوشش کرتا ہے — گیٹ وے کال بیک دو بار موصول ہوتی ہے، کوئی ایڈمن ناکام پروویژن کو دوبارہ چلاتا ہے، یا گاہک ڈبل کلک کرتا ہے۔ اس کے بغیر دوسری کوشش ایک دوسری سائٹ بنا دے گی اور آپ سے اس کا بل لیا جائے گا۔ دونوں ماڈیولز اور PHP کلائنٹ آپ کے لیے یہ کام کرتے ہیں؛ اگر آپ براہ راست API کو کال کر رہے ہیں، تو Idempotency-Key بھیجیں۔

تین فیلڈز جنہیں چھوڑ دینا آسان ہے

ان میں سے ہر ایک پورے عمل کو خراب کر دیتا ہے، اور کوئی بھی تصدیقی غلطی کے سوا کسی اور صورت میں سامنے نہیں آتا — سوائے پہلے کے، جو بالکل کچھ نہیں کے طور پر ظاہر ہوتا ہے:

• ⛔⛔ کلائنٹ کو ان کی پہلی سائٹ کی فراہمی سے پہلے کسی پلان میں شامل کیا جانا چاہیے، 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} سے ڈومین دوبارہ پڑھیں: اس کا موازنہ سائٹ کے اپنے بنیادی ڈومین سے کیا جاتا ہے اور کبھی بھی کسی عرفی نام (alias) سے نہیں کیا جاتا۔

صرف جملہ نہیں، پوری خرابی پڑھیں

توثیق مسترد ہونے کا پیغام جان بوجھ کر عمومی ہوتا ہے — "The request was well-formed but failed validation." — کیونکہ قابل عمل حصہ details میں ہوتا ہے، جو فیلڈ اور اس کی وجہ بتاتا ہے۔ دونوں ماڈیولز اور PHP کلائنٹ اسے اس پیغام کے ساتھ منسلک کرتے ہیں جو وہ آپ کے ایڈمن کو دکھاتے ہیں۔ اگر آپ خود API کال کر رہے ہیں تو error.details پڑھیں؛ کچھ اندراجات میں جملے کے بجائے صرف ایک ویلیو ہوتی ہے، جس کی وجہ سے جب آپ کے ری سیلر پلان میں گنجائش نہیں ہوتی تو max_sites: 0 آپ تک پہنچتا ہے۔

اپنے پہلے آرڈر سے پہلے

وہ سائٹس جو آپ کے کلائنٹس خریدتے ہیں وہ آپ کے ری سیلر پلان کے سائٹ الاؤنس میں شمار ہوتی ہیں، اس لیے آپ کو ایسے پلان کی ضرورت ہے جس میں گنجائش ہو۔ کنکشن ٹیسٹ اس کا پتہ نہیں لگا سکتا — یہ آپ کے پروگرام کو پڑھتا ہے اور کچھ بھی فراہم نہیں کرتا — اس لیے یہ ایک فعال اکاؤنٹ کی رپورٹ دیتا ہے جو ابھی فروخت نہیں کر سکتا۔ الاؤنس کے بغیر دیا گیا آرڈر مسترد کر دیا جاتا ہے اور ساتھ میں بالکل یہی بتانے والا پیغام دیا جاتا ہے۔

اپنے ڈاؤن لوڈ کی تصدیق کریں

دونوں آرکائیوز ہمارے اپنے ہوسٹ نام سے TLS پر پیش کیے جاتے ہیں، کبھی کہیں اور ری ڈائریکٹ نہیں کیے جاتے، اور ان کے SHA-256 چیک سمز ڈاؤن لوڈز صفحہ پر ڈاؤن لوڈ لنکس کے ساتھ درج ہوتے ہیں۔