Para sa mga developer
Ang Zinn Digital® ay isang platform na API-first. Ang mismong engine API na nagpapagana sa aming dashboard ay ang makukuha mo — may bersyon, spec-first at 100% na dokumentado sa oras ng build, na may mga ginawang SDK, isang CLI, isang Terraform provider, mga naka-sign na webhook at isang MCP server sa ibabaw nito. Anuman ang gamitin mo sa pagtatrabaho — isang terminal, isang pipeline, isang state file o isang AI agent — ang platform ay tumutugon dito.
Karamihan sa mga host ay nagdaragdag lang ng API sa control panel pagkatapos, at halata ito — ang kalahating feature ng panel ay hindi kailanman lumalabas. Kami ay nagtayo sa kabilang paraan. Ang dashboard, ang admin console, ang CLI, ang Terraform provider, ang MCP server, at ang iyong sariling mga integrasyon ay gumagamit lahat ng parehong engine API. Kung kaya mong gawin sa panel, kaya mo ring gawin sa code.
Ang detalye ng OpenAPI ang pinagmumulan ng katotohanan, at walang endpoint na inilalabas maliban kung ito ay nasa detalye. Ang iisang panuntunang iyon ang nagiging dahilan upang ang pampublikong API ay ganap na nakadokumento sa oras ng pagbuo sa halip na sa bandang huli — walang sulok na hindi nakadokumento, dahil ang isang hindi nakadokumentong endpoint ay hindi maaaring umiral.
Ang mga interactive reference doc, ang apat na client SDK, ang karamihan sa CLI, at ang Terraform provider scaffolding ay sabay-sabay na ginagawa mula sa iisang spec na iyon. Isang pinagmulan, maraming artepakto, laging magkakasabay — hinding-hindi mo hahabulin ang isang dokumentong nalayo sa implementasyon.
Nasa ilalim ng /v1 ang mga endpoint na may inilathala na patakaran sa pag-depreciate at isang changelog. Binibigyan ka ng abiso bago may magbago, sa pamamagitan ng sulat, sa halip na malaman ito mula sa isang nabigong build.
Tumatakbo ang mga contract test ng implementation laban sa spec at ang OpenAPI linting sa bawat pagbabago. Pinatutuklas ng drift sa pagitan ng code at ng contract na nabigo ang build — kaya ang spec na pinagbuhatan mo ng iyong client ay ang spec na talagang sinusunod ng server.
Dalawang paraan papasok, iisang parehong prinsipyo ang nasa likod ng mga ito. Alinman ang gamitin mo, malalapat ang magkatulad na mga pagsusuri sa pahintulot at ang parehong paghihiwalay sa antas ng database.
Ang mga key ay may anyong zdk_<mode>_<prefix>_<secret>. Isang SHA-256 hash lamang ng secret ang nakaimbak — hindi na namin maipapakita sa iyo muli ang isang key pagkatapos itong ilabas, at gayundin ang sinumang makakaabot sa aming database. May mga saklaw ang mga key, maaaring bawiin, at inilalabas bawat organisasyon sa halip na bawat tao.
Maghiwalay ang mga sandbox key sa production key at tumatakbo ang mga ito sa sandbox mode: walang totoong bayarin, walang totoong pag-provision. Mapapatakbo nang husto ng iyong mga integration test ang API nang walang ginagastos na pera o nagtatayo ng mga server.
Ang mga sesyon ng user ay nag-a-authenticate gamit ang mga JWT na inisyu ng Keycloak, na sini-verify laban sa pampublikong key ng realm, at nire-resolve sa parehong Principal object na ginagawa ng isang API key. Ang mga endpoint ay nagbabantay sa mga granular na permission key tulad ng sites.create o apikeys.manage, na sinusuri sa bawat organisasyon — ang pahintulot sa isang org ay hindi nagbibigay ng access sa isang hiwalay at walang kaugnayang org, bagama't nalalapat ito sa mga org na naka-nest sa ilalim nito.
Ang bawat kahilingan ng tenant ay tumatakbo sa isang transaksyon kung saan nakatakda ang Postgres org scope mula sa principal, kaya ang isolation ay ipinapatupad ng database, hindi ng ORM filter na maaaring makalimutan ng sinuman. Naroon pa rin ang queryset filter bilang defense in depth.
Madaling pagandahin ang isang API sa isang README at mahirap panatilihing maayos sa ilalim ng totoong trapiko. Ito ang mga bahaging pinaghirapan namin, dahil ito ang mga bahaging sumisira sa mga integrasyon alas-tres ng umaga.
Ang isang detalyeng nararapat banggitin, dahil hinuhubog nito kung paano kumikilos ang maramihang gawain: ang 409 sa dobleng domain ay sumasagot sa "ang hostname ba na ito ay naka-host dito?" para sa anumang tenant, na isang enumeration oracle at totoong panganib sa deanonymisation laban sa Footprint-Free. Ang pag-throttle sa paggawa ng site sana ang naging madaling solusyon at sinira sana nang tuluyan ang produktong bulk-provisioning. Sa halip, ang mga tinanggihang pagtatangka sa dobleng domain lamang ang may badyet, bawat principal. Ang mga matagumpong paggawa ay hindi kailanman sinisingil dito — kaya maaari kang mag-provision nang maramihan buong araw, at agad na namamatay ang pag-probe.
Tatlong consumer na may parehong spec, para sa tatlong magkakaibang paraan ng pagtatrabaho.
Binuo para sa TypeScript, Python, PHP, at Go, sinusundan ang spec para ang isang bagong endpoint ay dumating sa iyong wika nang hindi naghihintay sa isang isinulat sa kamay na wrapper.
Gumawa ng isang WordPress site, patakbuhin ito nang lokal na walang naka-install kundi Node, at i-deploy ito. Sinusuri ng Zinnector® ang iyong proyekto laban sa slot na ia-deploy mo — bersyon ng PHP, disk, bilang ng file — at nagbibigay ng babala bago ka mag-push sa halip na pagkatapos. Nag-a-sign in din ito, naglilista ng mga site, nag-a-deploy, namamahala ng mga domain at DNS, nagbabasa ng mga serbisyo ng mail, gumagawa ng mga backup, nagpapatakbo ng mga naka-allowlist na WP-CLI, nag-te-tail ng mga log, at nagsasagawa ng mga bulk operation. Libre, lisensyado sa ilalim ng MIT, at binuo sa parehong pampublikong API na ito.
Pamahalaan ang mga site, domain, DNS record, mailbox, at plan bilang infrastructure as code. Ang terraform apply ang naglalaan ng hosting, at ang iyong mga kapaligiran ay nagiging madaling kopyahin at suriin sa halip na maging sunud-sunod na pag-click na walang nagtala.
Mga nabuong dokumento na mababasa at matatawag mo mula sa browser, na naglalarawan nang eksakto sa mga endpoint na ipinapatupad ng server — dahil pareho silang nagmula sa iisang spec.
Sa likod ng platform ay ang isang matibay na event spine: ang bawat pagbabago sa estado ay nagsusulat ng event sa isang transaksyonal na outbox sa Postgres, kasabay ng pagbabago sa database, at ini-publish ito ng isang relay sa NATS JetStream. May uri at bersyon ang mga event — site.deployed, order.paid, invoice.overdue, backup.completed, abuse.flagged, trial.ending at ang iba pa.
Magrehistro ng isang endpoint bilang isang WebhookSubscription at piliin ang mga uri ng kaganapan na matatanggap nito. Isang stream ang nagpapakain sa mga abiso, analytics, mga automation at sa iyong pagsasama — kinokonsumo mo ang parehong mga kaganapang ginagamit namin.
Ang bawat delivery ay may lagdang HMAC para mapatunayan mong galing sa amin bago ka umaksyon dito.
Ang mga nabigong paghahatid ay sinusubukang muli nang may backoff at ang bawat pagtatangka ay naitatala bilang isang WebhookDelivery. Maaari mong suriin at i-replay ang mga paghahatid mula sa dashboard sa halip na mag-email sa suporta upang itanong kung ano ang aming ipinadala.
Sadya umanong at-least-once ang pipeline sa halip na magpanggap na exactly-once. Ang isang relay na namatay habang naglalathala ay mapapaso ang claim lease at muling ilalathala ang mga event nito. Mag-dedupe sa envelope id at tama na ang iyong consumer sa pamamagitan ng konstruksyon.
Kalahati lamang ng kuwento ng isang developer ang API. Ang kalahati pa ay ang pag-deploy.
Inilalantad namin ang platform bilang isang naka-host na MCP server: isang manipis na protocol adapter sa engine API na muling gumagamit ng magkatulad na action catalogue, RBAC, at audit trail. Ikonekta ang Claude Code, Cursor, ChatGPT, Claude Desktop o anumang client na may kakayahang MCP nang isang beses, at ang bawat kakayahang idinaragdag namin sa API ay awtomatikong magiging available dito.
Kumukuha ang ahente ng tatlong bagay: Mga Tool (ang parehong mga API endpoint, walang parallel na lohika na lilihis), Mga Mapagkukunan (read-only na kalusugan ng site, config, mga kamakailang log, sukatan, uptime, at mga artikulo sa KB, kaya nagdidagnosis ito gamit ang totoong data bago umaksyon) at Mga Prompt (mga nai-publish na template ng daloy ng trabaho gaya ng "diagnose this site" o "prepare a migration").
Pareho lang ang kwento ng kaligtasan at pagpapatunay: OAuth 2.1, mga token na nakatali sa iyong org at mga pahintulot ng RBAC na may ipinapatupad na row-level security, may saklaw at maaaring bawiin sa bawat tool, hiwalay ang sandbox sa production. Ang mga mapanirang aksyon — delete, suspend, billing, malaking gastusin — ay nangangailangan ng tahasang kumpirmasyon o patakaran ng pag-apruba ng tao. Ang mga rate limit at cap sa gastusin ay nakatali sa mga bayad na aksyong na-trigger ng AI, at ang bawat tawag sa MCP ay naka-audit-log kasama ang identity, tool, mga argumento, at resulta.
Sinusuportahan namin ang protocol sa halip na i-integrate ang bawat app nang paisa-isa, na nangangahulugang ang iyong pipiliing AI tooling ay maaaring magbago nang hindi na kailangang baguhin ang iyong hosting integration.
Oo — ito ay parehong engine API, nai-publish at pinatibay. Ang dashboard, admin console, CLI, Terraform provider, MCP server at webhooks ay lahat ng mga gumagamit ng isang ibabaw, kaya naman ang API ay hindi napag-iwanan sa panel.
Oo. Ang mga sandbox key ay hiwalay na ibinibigay sa mga production key at tumatakbo sa test mode: walang totoong pagsingil at walang totoong pag-provision. Ituro ang iyong CI sa mga sandbox credential at subukan nang ligtas ang buong cycle ng kahilingan at tugon.
Magpadala ng Idempotency-Key sa iyong POST. Ang replay record ay isinusulat sa commit sa halip na inline, kaya ang isang retry ay hindi kailanman makakapag-replay ng naka-cache na tagumpay para sa isang row na hindi naman talaga na-commit, at ang isang request na nabigo ay agad na naglalabas ng lock nito upang ang iyong itinamang retry ay hindi maantala. Ang paghahatid ng Webhook ay at-least-once ayon sa disenyo — i-dedupe sa envelope id sa iyong dulo.
Hindi ngayon. Ang mga API key ay ibinibigay bawat organisasyon, kaya ang isang integration na sumasaklaw sa ilang client org ay may hawak na key para sa bawat isa. Sinusuri rin ang mga pahintulot bawat organisasyon para sa mga user principal: ang pagkakaroon ng sites.create sa isang org ay hindi nagbibigay ng access sa hiwalay at hindi konektadong org, bagama't nalalapat ito sa mga org na naka-nest sa ibaba nito. Sinasadya iyon — nililimitahan nito ang nakompromisong key sa sarili nitong organisasyon at sa mga sub-org sa ilalim nito, hindi sa buong platform.
Ang tungkulin ng dev ay sumasaklaw sa pagbasa ng organisasyon, pamamahala ng API key, pagtingin at paggawa ng mga site, pag-restart sa mga ito, pag-purge ng kanilang cache, at pagtingin at pagtugon sa mga tiket. Sadyang hindi kasama rito ang kontrol sa pagsingil. Tandaan na ang mga pahintulot sa pag-deploy at push-to-live ay hindi bahagi nito — kung kailangan iyon ng isang miyembro ng koponan, magtalaga ng tungkulin na nagtataglay ng mga ito sa halip na ipagpalagay na ang Developer ang pinakamalawak na teknikal na tungkulin.
Ang mga pagpapadala ay muling sinusubukan nang may backoff at ang bawat pagtatangka ay naitatala bilang isang WebhookDelivery na maaari mong suriin. Sa upstream, ang mga kaganapan ay isinusulat sa isang transactional outbox sa loob ng parehong database transaction ng mismong pagbabago, kaya walang nawawala habang hindi available ang isang consumer — ang isang down na consumer ay nahuhuli, hindi nito sinisira ang producer, at maaari mong i-replay ang mga pagpapadala mula sa dashboard kapag bumalik na ito.
Magsimula sa 14-araw na pagsubok na walang kinakailangang card para sa Footprint-Free Hosting — walang detalye ng pagbabayad, hanggang 5 site. Ang mga bayarang tier ng Footprint-Free ay nagsisimula sa $6/mo para sa PBN 5. Ang bawat plano ay may kasamang 30-araw na garantiyang ibabalik ang pera, mga libreng migrasyon, at walang vendor lock-in.
Spec-first API, mga nabuong SDK, isang CLI, isang Terraform provider, mga lagdaang webhook, at isang MCP server — sa hosting na ginawa namin para sa mahigit 650,000 na site sa buong mundo. Magsimula sa isang 14-araw na pagsubok na walang kailangang card, walang mga detalye ng pagbabayad.
Magsimula nang libre