برای توسعه‌دهندگان

میزبانی که می‌توانید آن را از طریق کد مدیریت کنید

پلتفرم Zinn Digital® مبتنی بر رویکرد API-first است. همان API موتوری که پیشخوان ما را اجرا می‌کند، در اختیار شما نیز قرار می‌گیرد — دارای نسخه‌بندی، مبتنی بر مشخصات و با مستندسازی ۱۰۰٪ در زمان ساخت، همراه با SDKهای تولیدشده، یک CLI، ارائه‌دهنده Terraform، وب‌هوک‌های امضاشده و یک سرور MCP بر روی آن. برای کار از هر چه که استفاده کنید — پایانه، خط لوله، فایل وضعیت یا عامل هوش مصنوعی — این پلتفرم پاسخگوی آن است.

یک نقطه پایانی API که رویدادهای امضاشده را به چندین شنونده مشترک‌شده تحویل می‌دهد.
  • +۷۰۰٬۰۰۰سایت‌های میزبانی‌شده در سراسر جهان
  • ۱مشخصات OpenAPI که هر ابزار از آن تولید می‌شود
  • 4کیت‌های توسعه نرم‌افزار (SDK) کلاینت — TypeScript، Python، PHP، Go
  • OAuth 2.1دسترسی دارای دامنه و قابل ابطال عامل هوش مصنوعی

یک API. هر بستری بر پایه آن اجرا می‌شود.

بیشتر ارائه‌دهندگان هاستینگ، یک API را پس از اتمام کار روی کنترل پنل سوار می‌کنند و این کاملاً مشخص است — نیمی از ویژگی‌های پنل هرگز به آن راه پیدا نمی‌کنند. ما ساختار را دقیقاً برعکس پیاده‌سازی کردیم. داشبورد، کنسول ادمین، CLI، ارائه‌دهنده Terraform، سرور MCP و یکپارچه‌سازی‌های اختصاصی شما، همگی از همان API موتور اصلی استفاده می‌کنند. اگر می‌توانید آن را در پنل انجام دهید، می‌توانید در کد هم پیاده‌سازیش کنید.

ابتدا مشخصات، نه مستندسازی‌شده در آینده

مشخصات OpenAPI منبع اصلی حقیقت است و هیچ اندپوینتی عرضه نمی‌شود مگر اینکه در این مشخصات وجود داشته باشد. همین یک قانون باعث می‌شود که API عمومی به جای مستندسازی تدریجی در آینده، در همان زمان ساخت به طور کامل مستند شود — هیچ گوشه مستند نشده‌ای وجود ندارد، زیرا یک اندپوینت مستند نشده اصلاً نمی‌تواند وجود داشته باشد.

تولیدشده، بدون نگهداری دستی

مستندات مرجع تعاملی، چهار SDK کلاینت، بخش عمده‌ای از CLI و ساختار اولیه ارائه‌دهنده Terraform همگی از همان یک مشخصات فنی تولید می‌شوند. یک منبع، چندین خروجی، همیشه هماهنگ — شما هرگز به دنبال مستنداتی که از پیاده‌سازی فاصله گرفته‌اند نخواهید دوید.

نسخه‌بندی‌شده به همراه خط‌مشی منسوخ‌سازی

نقاط پایانی با خط‌مشی استهلاک منتشرشده و گزارش تغییرات در مسیر /v1 قرار دارند. قبل از ایجاد هر تغییری به‌صورت کتبی به شما اطلاع داده می‌شود، به‌جای اینکه از طریق خرابی بیلد متوجه آن شوید.

آزموده‌شده با قرارداد در CI

آزمون‌های تطابق پیاده‌سازی با مشخصات و اعتبارسنجی OpenAPI در هر تغییر اجرا می‌شوند. هرگونه مغایرت بین کد و قرارداد باعث شکست فرایند ساخت می‌شود — بنابراین مشخصاتی که کلاینت خود را از روی آن تولید می‌کنید، همان مشخصاتی است که سرور واقعاً رعایت می‌کند.

احراز هویت، تعیین دامنه و چالش‌های پنهان در مقیاس بالا

دو روش ورود، با یک اصل یکسان در پس آن‌ها. از هرکدام که استفاده کنید، همان بررسی‌های مجوز و همان جداسازی در سطح پایگاه داده اعمال می‌شود.

کلیدهای API، به ازای هر سازمان

کلیدها شبیه به zdk_<mode>_<prefix>_<secret> هستند. فقط یک هش SHA-256 از بخش محرمانه ذخیره می‌شود — ما نمی‌توانیم پس از صدور، کلید را دوباره به شما نشان دهیم و هیچ‌کس دیگری هم که به پایگاه داده ما دسترسی پیدا کند نمی‌تواند این کار را انجام دهد. کلیدها دارای محدوده هستند، قابل ابطال می‌باشند و به جای هر فرد، برای هر سازمان صادر می‌شوند.

حالت‌های زنده و آزمایشی، جدا از هم نگه‌داشته‌شده

کلیدهای Sandbox از کلیدهای محیط پروداکشن جدا هستند و در حالت Sandbox اجرا می‌شوند: بدون صورت‌حساب واقعی، بدون آماده‌سازی واقعی منابع. آزمون‌های یکپارچه‌سازی شما می‌توانند بدون صرف هزینه یا ایجاد سرورها، فشار بالایی به API وارد کنند.

OIDC برای انسان‌ها

نشست‌های کاربر با JWTهای صادرشده توسط Keycloak احراز هویت می‌شوند، در برابر کلید عمومی قلمرو (realm) تأیید اعتبار می‌گردند و به همان شیء Principal تبدیل می‌شوند که یک کلید API می‌شود. نقاط پایانی بر اساس کلیدهای دسترسی دقیق مانند sites.create یا apikeys.manage کنترل می‌شوند که به ازای هر سازمان بررسی می‌گردند — مجوز در یک سازمان هیچ دسترسی‌ای در سازمانی مجزا و نامرتبط اعطا نمی‌کند، هرچند که برای سازمان‌های زیرمجموعه آن اعمال می‌شود.

امنیت در سطح سطر در پایین

هر درخواست مستأجر در یک تراکنش اجرا می‌شود که محدوده سازمانی Postgres آن از هویت اصلی تعیین شده است، بنابراین تفکیک توسط پایگاه داده اعمال می‌شود، نه با فیلتر ORM که ممکن است کسی فراموش کند. فیلتر queryset همچنان به عنوان دفاع لایه‌ای وجود دارد.

ساخته‌شده برای ماشین‌ها، نه صرفاً برای دموها

زیبا جلوه دادن یک API در یک فایل README آسان است، اما به دست آوردن عملکرد مناسب آن در ترافیک واقعی دشوار است. این‌ها بخش‌هایی هستند که برایشان بسیار زحمت کشیده‌ایم، زیرا همان بخش‌هایی هستند که در ساعت سه بامداد ادغام‌ها را مختل می‌کنند.

یک جزئیات قابل توجه وجود دارد، زیرا نحوه عملکرد کارهای دسته‌ای را مشخص می‌کند: خطای ۴۰۹ در دامنه تکراری برای هر مستأجر به این پرسش پاسخ می‌دهد که «آیا این نام هاست در اینجا میزبانی می‌شود؟»، که یک اوراکل شمارش (enumeration oracle) و یک خطر واقعی برای فاش شدن هویت در برابر Footprint-Free است. محدود کردن سرعت ایجاد سایت (throttling) یک راه حل تنبلانه بود و محصول راه‌اندازی دسته‌ای را کاملاً از کار می‌انداخت. در عوض، فقط تلاش‌های رد شده برای دامنه‌های تکراری به ازای هر کاربر اصلی سهمیه‌بندی می‌شوند. ایجادهای موفق هرگز از این سهمیه کم نمی‌شوند — بنابراین شما می‌توانید در تمام طول روز به صورت دسته‌ای عملیات راه‌اندازی را انجام دهید، و تلاش‌های کاوشگرانه تقریباً بلافاصله متوقف می‌شوند.

  • یک قالب خطای منسجم در هر شکست: یک کد، یک پیام قابل خواندن، جزئیات اختیاری در سطح فیلد و یک request_id که می‌توانید به پشتیبانی ارائه دهید. خطاهای اعتبارسنجی همراه با ذکر فیلدهای دارای مشکل، کد 422 را بازمی‌گردانند.
  • کلیدهای پایاپای در POST، با ثبت رکورد بازپخش در زمان ثبت نهایی (commit) به جای درون‌خطی — به طوری که یک تلاش مجدد هرگز نمی‌تواند یک پاسخ 201 کش‌شده را بازپخش کند که نام سطری را بر زبان می‌آورد که هرگز ثبت نهایی نشده است. یک درخواست ناموفق بلافاصله قفل در حال اجرای خود را آزاد می‌کند، بنابراین یک 422 مانع تلاش مجدد تصحیح‌شده شما نمی‌شود.
  • صفحه‌بندی با مکان‌نما به‌صورت کلید‌مجموعه روی UUIDv7 — پایدار در زمان نوشتن‌های هم‌زمان، بدون لغزش صفحه هنگام درج سطرها در میانه پویش.
  • مقدار RateLimit-Remaining در پاسخ‌ها، تا کلاینت تولیدشده بتواند به‌جای حدس زدن، هوشمندانه پس‌نشینی کند.
  • منابع خارج از محدوده به جای 403 خطای 404 را برمی‌گردانند — کد 403 وجود منبع را تأیید می‌کند. فیلتر کردن بر اساس سازمانی خارج از محدوده شما نیز به همین دلیل یک صفحه خالی برمی‌گرداند.
  • ایجاد سایت یک ثبت‌نام است، نه آماده‌سازی: درخواست POST /v1/sites کد 201 را با وضعیت pending برمی‌گرداند و هرگز فرایند ساخت را مسدود نمی‌کند. این رویداد در همان تراکنشِ سطر، در transactional outbox نوشته می‌شود؛ بنابراین یک سایت تنها و تنها در صورتی وجود دارد که درخواست آماده‌سازی آن تضمین شده باشد.

کیت‌های توسعه نرم‌افزار (SDK)، یک CLI و یک ارائه‌دهنده Terraform

سه مصرف‌کننده از یک مشخصه، برای سه روش مختلف کاری.

کیت‌های توسعه نرم‌افزار (SDK) کلاینت

تولیدشده برای TypeScript، Python، PHP و Go، با ردیابی مشخصات تا نقطه پایانی جدید بدون انتظار برای یک پوشش دست‌نویس به زبان شما برسد.

Zinnector®، رابط خط فرمان (CLI)

ساختار یک سایت WordPress را ایجاد کنید، آن را به صورت محلی و تنها با نصب Node اجرا نمایید، و آن را مستقر کنید. Zinnector® پروژه شما را پیش از استقرار با اسلاتی که قصد استقرار روی آن را دارید بررسی می‌کند — نسخه PHP، دیسک، تعداد فایل‌ها — و به جای هشدار پس از ارسال، پیش از ارسال به شما هشدار می‌دهد. همچنین وارد سیستم می‌شود، سایت‌ها را فهرست می‌کند، مستقر می‌سازد، دامنه‌ها و DNS را مدیریت می‌کند، خدمات ایمیل را می‌خواند، نسخه پشتیبان تهیه می‌کند، WP-CLI مجاز را اجرا می‌کند، گزارش‌ها را به صورت زنده دنبال می‌کند و عملیات گروهی را به جریان می‌اندازد. رایگان، دارای مجوز MIT و ساخته‌شده بر روی همین API عمومی.

ارائه‌دهنده Terraform

سایت‌ها، دامنه‌ها، رکوردهای DNS، صندوق‌های پستی و پلن‌ها را به صورت زیرساخت به عنوان کد مدیریت کنید. دستور terraform apply هاستینگ را آماده‌سازی می‌کند و محیط‌های شما به جای توالی کلیک‌هایی که هیچ‌کس یادداشت نکرده است، قابل بازتولید و بررسی می‌شوند.

مرجع تعاملی

مستندات تولیدشده‌ای که می‌توانید از مرورگر بخوانید و فراخوانی کنید، که دقیقاً نقاط انتهایی پیاده‌سازی‌شده توسط سرور را توصیف می‌کند — زیرا هر دو از یک مشخصات یکسان سرچشمه می‌گیرند.

وب‌هوک‌هایی که در صورت از کار افتادن نقطه پایانی شما دوام می‌آورند

در پشت این پلتفرم، یک ستون فقرات پایدار از رویدادها قرار دارد: با هر تغییر وضعیت، یک رویداد به صورت اتمیک هم‌گام با تغییر پایگاه داده در یک صندوق خروجی تراکنشی در Postgres ثبت می‌شود و یک رله آن را در NATS JetStream منتشر می‌کند. رویدادها دارای نوع و نسخه هستند — site.deployed، order.paid، invoice.overdue، backup.completed، abuse.flagged، trial.ending و سایر موارد.

در موضوعات مورد علاقه خود مشترک شوید

یک نقطه پایانی را به‌عنوان WebhookSubscription ثبت کنید و انواع رویدادهایی را که دریافت می‌کند برگزینید. یک جریان واحد، اعلان‌ها، تجزیه‌وتحلیل‌ها، اتوماسیون‌ها و یکپارچه‌سازی شما را به‌طور یکسان تغذیه می‌کند — شما همان رویدادهایی را دریافت می‌کنید که ما مصرف می‌کنیم.

امضاشده با HMAC

هر تحویل دارای امضای HMAC است تا بتوانید پیش از اقدام روی آن، بررسی کنید که از طرف ما ارسال شده است.

با تأخیر مجدداً تلاش شد و ثبت گردید

تحویل‌های ناموفق با تأخیر تصاعدی دوباره تلاش می‌شوند و هر تلاش به عنوان WebhookDelivery ثبت می‌شود. می‌توانید به جای ارسال ایمیل به پشتیبانی برای پرسیدن اینکه چه چیزی ارسال کرده‌ایم، تحویل‌ها را از داشبورد بررسی و دوباره ارسال کنید.

حداقل یک بار، بنابراین موارد تکراری را بر اساس id حذف کنید

این خط لوله عمداً به صورت «حداقل یک بار» عمل می‌کند تا اینکه تظاهر به «دقیقاً یک بار» بودن نماید. بازپخش‌کننده‌ای که در میانه انتشار متوقف می‌شود، اجاره ادعای آن منقضی شده و رویدادهایش دوباره منتشر می‌شوند. بر اساس شناسه پاکت، عمل حذف تکرار را انجام دهید تا مصرف‌کننده شما از نظر ساختاری صحیح عمل کند.

انتقال کد به سایت

یک ای‌پی‌آی تنها نیمی از داستان یک توسعه‌دهنده است. نیم دیگر عرضه محصول است.

  • GitHub، GitLab یا Bitbucket را از طریق OAuth متصل کنید، در حالی که کلیدهای استقرار در مخزن اعتبارنامه‌ها نگهداری می‌شوند — نه در یک فایل پیکربندی.
  • عملیات Push یک خط لوله ساخت و استقرار را فعال می‌کند، همراه با نگاشت شاخه به محیط (main به production، staging به staging) و مراحل ساخت به ازای هر پشته برای composer و npm.
  • در صورت بروز خطا در استقرار، به نسخه قبلی بازگردید.
  • ایجاد نسخه آزمایشی و انتقال به سایت اصلی، تا هر تغییری پیش از رسیدن به بازدیدکنندگان در محیطی واقعی بررسی و تأیید شود.
  • دسترسی SFTP برای هر سایت تحت ایزولاسیون CageFS، به طوری که هر کاربر فقط فایل‌های خود را می‌بیند، به همراه یک پوسته محدودشده (jailed) SSH در بستر اشتراکی.
  • wp-cli از ترمینال کنترل‌پنل و از طریق SSH.
  • VS Code در مرورگر از طریق code-server — یک ویرایشگر کامل همراه با git، برای ویرایش مستقیم فایل‌های سایت.
  • نسخه PHP اختصاصی برای هر سایت، تنظیمات قابل ویرایش PHP، افزونه‌های اختصاصی برای هر سایت، متغیرهای محیطی و cron واقعی در کنار WP-cron.

چهار روش برای کار روی یک سایت

ای‌پی‌آی یکی از درها است. این‌ها چهار در دیگر هستند، و هر یک از آن‌ها به جای این‌که به عنوان سطح توسعه‌دهنده فروخته شوند، در پلن گنجانده شده‌اند.

ویرایشگر وب

نرم‌افزار VS Code در مرورگر، باز شده از صفحه سایت در داشبورد، که فایل‌های واقعی آن سایت را با git داخلی و کل ویرایشگر در همان محیط ایزوله CageFS مربوط به دسترسی SFTP شما ویرایش می‌کند. این ابزار سایت زنده (LIVE) را ویرایش می‌کند — هیچ نسخه مرحله‌ای (staging) در این بین وجود ندارد، بنابراین فایلی که ذخیره می‌کنید در همان لحظه نوشته شدن عمومی می‌شود، اگرچه ممکن است ارائه یک فایل استاتیک از حافظه پنهان CDN تا چهار ساعت ادامه یابد.

Zinnector®، رابط خط فرمان (CLI)

رایگان، دارای مجوز MIT و ساخته‌شده بر روی همین API عمومی. اسکلت‌بندی یک سایت WordPress را ایجاد کنید، آن را روی دستگاه خود اجرا نمایید، پیش از استقرار، آن را با اسلاتی که قصد استقرار بر روی آن را دارید بررسی نمایید — نسخه PHP، دیسک، تعداد فایل‌ها — و مستقر سازید. به Node 24 یا جدیدتر نیاز دارد.

سرور MCP

یک کاتالوگ از ابزارها، تا کلاینت هوش مصنوعی که در حال حاضر استفاده می‌کنید بتواند از طریق همان API و همان مجوزهایی که پیشخوان استفاده می‌کند، روی سایت‌های شما کار کند. همان سروری که کلاینت خودتان به آن متصل می‌شود، به ویرایشگر وب نیز متصل است. فقط-خواندنی، مگر اینکه خلاف آن را مشخص کنید.

دسترسی توسعه‌دهنده به ازای هر سایت

کار با مشتری نیازی به رمز عبور شما ندارد. فردی را از طریق نشانی ایمیل دعوت کنید و دقیقاً به یک سایت دسترسی خواهد داشت: آن‌ها با هویت خود، با نقش بیننده، ویرایشگر یا مدیر وارد می‌شوند، و هر سایت دیگری قبل از اجرای هر گرداننده‌ای، پاسخ ۴۰۴ می‌دهد — یک خط‌مشی امنیتی در سطح ردیف Postgres و یک مانع در سطح درخواست، نه فقط یک بررسی ساده. مالک حساب آن را با یک کلیک اعطا و لغو می‌کند که از درخواست بعدی آن‌ها اعمال می‌شود.

و همان API که عامل هوش مصنوعی شما می‌تواند استفاده کند

ما این پلتفرم را به‌عنوان یک سرور میزبانی‌شدهٔ MCP ارائه می‌دهیم: یک آداپتور پروتکل سبک بر روی API موتور که از همان کاتالوگ عملیات، RBAC و ردپای بازرسی استفاده مجدد می‌کند. کافی است Claude Code، Cursor، ChatGPT، Claude Desktop یا هر کلاینت سازگار با MCP را یک بار متصل کنید، و هر قابلیتی که به API اضافه کنیم به‌طور خودکار در دسترس آن قرار خواهد گرفت.

عامل سه چیز دریافت می‌کند: ابزارها (همان نقاط پایانی API، بدون منطق موازی که منحرف شود)، منابع (سلامت سایت فقط خواندنی، پیکربندی، گزارش‌های اخیر، معیارها، زمان فعال بودن و مقالات پایگاه دانش، تا قبل از اقدام با داده‌های واقعی تشخیص دهد) و دستورها (الگوهای گردش کار منتشر شده مانند «این سایت را تشخیص دهید» یا «یک مهاجرت آماده کنید»).

امنیت همان روندی را دارد که احراز هویت دارد: OAuth 2.1، توکن‌های وابسته به سازمان شما و مجوزهای RBAC همراه با اعمال امنیت در سطح سطر، با دامنه مشخص و قابل ابطال برای هر ابزار، و محیط آزمایشی (سندباکس) جدا شده از محیط تولید. اقدامات مخرب — حذف، تعلیق، صورت‌حساب، هزینه‌های بالا — نیازمند تأیید صریح یا خط‌مشی تأیید انسانی هستند. محدودیت‌های نرخ و سقف هزینه‌ها اقدامات پولی را که توسط هوش مصنوعی فعال می‌شوند محدود می‌کنند، و هر فراخوانی MCP با هویت، ابزار، آرگومان‌ها و نتیجه در گزارش حسابرسی ثبت می‌شود.

ما به جای یکپارچه‌سازی تک‌تک برنامه‌ها از پروتکل پشتیبانی می‌کنیم، به این معنی که انتخاب ابزارهای هوش مصنوعی شما می‌تواند بدون تغییر در یکپارچه‌سازی هاستینگ شما تغییر کند.

پرسش‌های متداول

آیا API عمومی همان موردی است که داشبورد استفاده می‌کند؟

بله — این همان API موتور است که منتشر و مقاوم‌سازی شده است. داشبورد، کنسول مدیریت، CLI، ارائه‌دهنده Terraform، سرور MCP و وب‌هوک‌ها همگی مصرف‌کننده یک سطح هستند، به همین دلیل است که API از پنل عقب نمی‌ماند.

آیا می‌توانم بدون صرف هزینه یا راه‌اندازی سرورهای واقعی، یکپارچه‌سازی را آزمایش کنم؟

بله. کلیدهای Sandbox جدا از کلیدهای تولید صادر می‌شوند و در حالت آزمایشی اجرا می‌شوند: بدون صورت‌حساب واقعی و بدون راه‌اندازی واقعی سرویس. سیستم CI خود را به سمت اعتبارنامه‌های sandbox هدایت کنید و چرخه کامل درخواست و پاسخ را با اطمینان آزمایش نمایید.

چگونه می‌توانم از ایجاد دو مورد از یک چیز توسط تلاش مجدد جلوگیری کنم؟

یک Idempotency-Key در درخواست POST خود ارسال کنید. رکورد بازپخش در زمان commit و نه به‌صورت درخط نوشته می‌شود، بنابراین تلاش مجدد هرگز نمی‌تواند یک موفقیت ذخیره‌شده در حافظه پنهان را برای ردیفی که واقعاً commit نشده است، بازپخش کند، و درخواستی که ناموفق باشد قفل خود را بلافاصله آزاد می‌کند تا تلاش مجدد اصلاح‌شده شما معطل نشود. تحویل Webhook بر اساس طراحی حداقل یک‌بار (at-least-once) است — موارد تکراری را بر اساس envelope id در سمت خود حذف کنید.

آیا می‌توانم به یک کلید API برای دسترسی به همه سازمان‌های مشتریانم مجوز بدهم؟

امروز نه. کلیدهای API برای هر سازمان صادر می‌شوند، بنابراین یکپارچه‌سازی‌ای که چند سازمان مشتری را در بر می‌گیرد، برای هر کدام یک کلید دارد. مجوزها نیز برای نهادهای کاربری به ازای هر سازمان بررسی می‌شوند: داشتن sites.create در یک سازمان، هیچ دسترسی در یک سازمان مجزا و نامرتبط ایجاد نمی‌کند، اگرچه برای سازمان‌های زیرمجموعه آن اعمال می‌شود. این امر عامدانه است — یک کلید افشا شده را به سازمان خودش و سازمان‌های فرعی زیر آن محدود می‌کند، نه به کل پلتفرم.

نقش پیش‌فرض توسعه‌دهنده در واقع چه مجوزهایی می‌دهد؟

نقش dev شامل خواندن اطلاعات سازمان، مدیریت کلیدهای API، مشاهده و ایجاد سایت‌ها، راه‌اندازی مجدد آن‌ها، پاک کردن حافظه پنهان (کش) آن‌ها، و همچنین مشاهده و پاسخ به تیکت‌ها می‌شود. این نقش عمداً کنترل صورت‌حساب را مستثنی می‌کند. توجه داشته باشید که مجوزهای استقرار (deploy) و push-to-live بخشی از آن نیستند — اگر یکی از اعضای تیم به آن‌ها نیاز دارد، به جای اینکه فرض کنید Developer جامع‌ترین نقش فنی است، نقشی را به او اختصاص دهید که شامل این مجوزها باشد.

اگر نقطه پایانی من به مدت یک ساعت از کار بیفتد، چه اتفاقی برای وب‌هوک‌های من می‌افتد؟

تحویل‌ها با عقب‌نشینی (backoff) مجدداً تلاش می‌شوند و هر تلاش به عنوان یک WebhookDelivery ثبت می‌شود که می‌توانید آن را بازرسی کنید. در بالادست، رویدادها در همان تراکنش پایگاه داده مربوط به خود تغییر در یک صندوق خروجی تراکنشی نوشته می‌شوند، بنابراین در حالی که مصرف‌کننده در دسترس نیست هیچ چیزی از دست نمی‌رود — مصرف‌کننده از کار افتاده دچار تأخیر می‌شود، اما هرگز تولیدکننده را متوقف نمی‌کند، و پس از بازگشت می‌توانید تحویل‌ها را از داشبورد دوباره اجرا کنید.

هزینه شروع توسعه بر پایه آن چقدر است؟

دوره آزمایشی ۱۴ روزه میزبانی Footprint-Free را بدون نیاز به کارت آغاز کنید — بدون اطلاعات پرداخت، تا ۵ سایت. پلن‌های پولی Footprint-Free از ۶ دلار در ماه برای PBN 5 شروع می‌شوند. تمام پلن‌ها دارای ۳۰ روز ضمانت بازگشت وجه، انتقال رایگان و بدون وابستگی به ارائه‌دهنده هستند.

مشخصات را بخوانید، سپس بر اساس آن بسازید

ای‌پی‌آی مبتنی بر مشخصات فنی، کیت‌های توسعه نرم‌افزار تولیدشده، یک رابط خط فرمان، ارائه‌دهنده ترافورم، وبهوک‌های امضاشده و یک سرور ام‌سی‌پی — در هاستینگی که برای بیش از ۷۰۰٬۰۰۰ سایت در سراسر جهان ساخته‌ایم. بدون نیاز به کارت و اطلاعات پرداخت، دوره آزمایشی ۱۴ روزه خود را آغاز کنید.

رایگان شروع کنید

افزونه‌های WordPress که ایجنت هوش مصنوعی شما می‌تواند با آن‌ها کار کند

هر یک از این افزونه‌ها سایت WordPress شما را به یک سرور MCP تبدیل می‌کنند، بنابراین Claude، Cursor، VS Code و سایر دستیارهای هوش مصنوعی می‌توانند کارهای واقعی روی آن انجام دهند، با حساب کاربری شما وارد شوند و به کارهایی که مجاز به انجام آن‌ها هستید محدود باشند.

تمام مستندات MCP و API برای توسعه‌دهندگان →