اگر از WHMCS استفاده میکنید، به جای این از ماژول WHMCS استفاده نمایید — این صفحه برای موارد دیگر است. دو گزینه وجود دارد که هر دو رایگان و هر دو تحت مجوز GPL-2.0-or-later هستند.
HostBill
یک ماژول هاستینگ با همان شش عملیات ماژول WHMCS.
۱. آن را دانلود کنید و از حالت فشرده خارج نمایید. ۲. دایرکتوری zinn را در includes/modules/Hosting/ بارگذاری کنید تا فایلها در includes/modules/Hosting/zinn/class.zinn.php و includes/modules/Hosting/zinn/ZinnHostBillClient.php قرار گیرند. ۳. به مسیر Settings → Modules → Hosting بروید، Zinn Digital® را فعال کنید و یک اتصال اضافه نمایید:
- API address:
https://api.zinndigital.com
- API key: کلید API مربوط به Zinn® شما (یک فیلد
password، بنابراین HostBill آن را بهصورت رمزگذاریشده ذخیره میکند)
۴. روی محصول، گزینههای Product line (مثلاً mainstream)، Stack (بهطور پیشفرض wordpress)، و در صورت تمایل Application و PHP version را تنظیم کنید. ۵. روی 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. کلیدی که در یک پنل صورتحساب جایگذاری میکنید باید بتواند مشتری را به دلیل عدم پرداخت معلق کند و او را وارد سیستم نماید؛ این کلید نباید قادر به بازنویسی اطلاعات اعتباری درگاه پرداخت خود شما باشد.
دو قانونی که در صورت نقض شدن هزینه مالی در پی دارند
۱. حساب را بر اساس CUSTOMER خود و سایت را بر اساس SERVICE خود کلیدگذاری کنید. سفارش دوم مشتری باید در حسابی که از قبل دارد قرار گیرد. اگر هر دو را بر اساس سرویس کلیدگذاری کنید، یک مشتری در نهایت با سه حساب نامرتبط و سه پنل کنترل جداگانه مواجه میشود. ۲. در هر ایجاد، یک کلید یکتایی (idempotency key) ارسال کنید که از شناسه خودتان برای آن مورد مشتق شده باشد. هر سیستم صورتحسابی مجدداً تلاش میکند — یک کالبک درگاه دو بار دریافت میشود، یک مدیر فرایند تحویل ناموفق را دوباره اجرا میکند، یک مشتری دو بار کلیک میکند. بدون آن، تلاش دوم یک سایت دوم ایجاد میکند و هزینه آن برای شما منظور میشود. هم ماژولها و هم کلاینت 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}` بخوانید: این مقدار با دامنه اصلی خود سایت مقایسه میشود و هرگز با یک نام مستعار مقایسه نمیگردد.
کل پیام خطا را بخوانید، نه فقط جمله را
پیام رد اعتبارسنجی عمداً عمومی است — "The request was well-formed but failed validation." — زیرا نیمی از اطلاعات قابل اقدام در details قرار دارد که نام فیلد و دلیل آن را مشخص میکند. هر دو ماژول و کلاینت PHP آن را به پیامی که به مدیر شما نشان میدهند پیوست میکنند. اگر خودتان API را فرامیخوانید، error.details را بخوانید؛ برخی از ورودیها به جای یک جمله حاوی یک مقدار صرف هستند، یعنی همان شیوهای که وقتی طرح نمایندگی شما فضا ندارد max_sites: 0 به دست شما میرسد.
پیش از نخستین سفارش شما
سایتهایی که مشتریان شما خریداری میکنند جزو سهمیه سایت طرح نمایندگی شما محسوب میشوند، بنابراین به یک طرح با فضای خالی نیاز دارید. آزمون اتصال نمیتواند این را تشخیص دهد — برنامه شما را میخواند و چیزی راهاندازی نمیکند — بنابراین گزارش یک حساب سالم را ارائه میدهد که هنوز نمیتواند بفروشد. سفارشی که بدون سهمیه ثبت شود با پیامی دقیقاً حاوی همین مضمون رد خواهد شد.
فایل دانلودی خود را تأیید کنید
هر دو آرشیو از طریق TLS از نام میزبان خود ما ارائه میشوند، هرگز به جای دیگری تغییر مسیر نمیدهند، و چکسامهای SHA-256 آنها در کنار پیوندهای دانلود در صفحه دانلودها درج شده است.