Fejlesztőknek
A Zinn Digital® egy API-központú platform. Pontosan ugyanazt a motor-API-t kapja meg, amely a vezérlőpultunkat is működteti – verziózott, specifikáció-alapú és 100%-ban dokumentált a fordítás idején, generált SDK-kkal, CLI-vel, Terraform-szolgáltatóval, aláírt webhookokkal és egy mindezek felett futó MCP-kiszolgálóval. Bármit is használ a munkához – terminált, folyamatot, állapotfájlt vagy AI-ügynököt –, a platform válaszol rá.
A legtöbb szolgáltató utólag illeszt egy API-t a vezérlőpulthoz, és ez meg is látszik – a funkciók fele sosem érhető el rajta keresztül. Mi fordítva építettük fel. A vezérlőpult, az adminisztrációs konzol, a CLI, a Terraform-szolgáltató, az MCP-kiszolgáló és a saját integrációid mind ugyanazt a motor-API-t használják. Amit megtehetsz a panelen, azt megteheted kódban is.
Az OpenAPI-specifikáció az igazság forrása, és egyetlen végpont sem élesedik, hacsak nem szerepel benne. Ez az egyetlen szabály az, ami miatt a nyilvános API már a build időpontjában teljesen dokumentált, nem pedig utólag – nincsenek dokumentálatlan részek, mert dokumentálatlan végpont nem létezhet.
Interaktív referenciadokumentációk, a négy kliens SDK, a CLI nagy része és a Terraform-szolgáltató vázai mind ebből az egy specifikációból generálódnak. Egy forrás, számos összetevő, mindig szinkronban – soha többé nem kell olyan dokumentációt keresnie, amely eltért a megvalósítástól.
A végpontok a /v1 alatt érhetők el közzétett elavulási szabályzattal és változásnaplóval. Írásos értesítést kap a változásokról, mielőtt azok életbe lépnének, így nem a elbukott buildből kell kiderítenie azokat.
A megvalósítás és a specifikáció közötti szerződéses tesztek és az OpenAPI-ellenőrzések minden módosításnál lefutnak. A kód és a szerződés közötti eltérés meghiúsítja az építést – így az a specifikáció, amelyből az ügyfelet generálja, az a specifikáció, amelyet a szerver a valóságban is tiszteletben tart.
Kétféle belépési mód, mögöttük egyetlen egységes elv. Bármelyiket is használja, ugyanazok a jogosultság-ellenőrzések és ugyanez az adatbázis-szintű izoláció érvényesül.
A kulcsok a zdk_<mode>_<prefix>_<secret> formátumúak. A titkos kulcsnak csak a SHA-256 hash értéke kerül tárolásra — a kiadást követően a kulcsot nem tudjuk újonnan megjeleníteni, és senki sem tudja, aki hozzáfér az adatbázisunkhoz. A kulcsok hatókörökkel rendelkeznek, visszavonhatók, és személyenként helyett szervezetenként kerülnek kiadásra.
A homokozó kulcsok különállnak éles kulcsaitól, és a homokozó módban futnak: nincsen valós számlázás, nincsen valós kiépítés. Az integrációs tesztek anélkül terhelhetik az API-t, hogy pénzt költene vagy szervereket építene.
A felhasználói munkamenetek a Keycloak által kibocsátott JWT-kkel hitelesítenek, amelyeket a realm nyilvános kulcsa ellenőriz, és ugyanazzá a Principal objektummá oldódnak fel, mint egy API-kulcs. A végpontok részletes engedélykulcsok alapján szűrnek, mint például a sites.create vagy apikeys.manage, amelyeket szervezetenként ellenőriznek – az egyik szervezetben lévő engedély nem biztosít hozzáférést egy másik, független szervezetben, bár érvényes az alatta beágyazott szervezetekre.
Minden bérlői kérés egy olyan tranzakcióban fut, amelynél a Postgres szervezet hatóköre a főszereplőtől van beállítva, így az elszigetelést maga az adatbázis kényszeríti ki, nem pedig egy ORM-szűrő, amelyet valaki esetleg elfelejthet. A lekérdezéskészlet-szűrő továbbra is jelen van mélységi védelemként.
Egy API-t könnyű jól mutatni egy README-ben, és nehéz rávenni, hogy valós forgalom alatt is megfelelően működjön. Ezek azok a részek, amelyeken keményen dolgoztunk, mert ezek azok, amelyek hajnali háromkor elrontják az integrációkat.
Egy részletet érdemes kiemelni, mivel ez határozza meg a tömeges műveletek működését: a duplikált domainre érkező 409-es válasz bármelyik bérlő számára megadja a választ arra, hogy „ez a hosztnév itt van-e hosztolva?”, ami egy enumerációs orákulum, és valós deanonymizálási kockázatot jelent a Footprint-Free rendszerrel szemben. A webhelylétrehozás korlátozása (throttling) lett volna a lustább megoldás, és önmagában tönkretette volna a tömeges kiépítést (bulk-provisioning) támogató terméket. Ehelyett csak a elutasított duplikált domain kísérletek kerülnek korlátozás alá, principalszinten. A sikeres létrehozásokat soha nem terhelik ezzel – így egész nap végrehajthatja a tömeges kiépítést, míg a vizsgálódás szinte azonnal megszűnik.
Három egyforma specifikációjú fogyasztó három különböző munkavégzési módhoz.
TypeScripthez, Pythonhoz, PHP-hez és Go-hoz generálva, követve a specifikációt, így egy új végpont kézzel írt wrapperre való várakozás nélkül érkezik meg az Ön nyelvére.
Hozzon létre egy WordPress webhelyet, futtassa helyben anélkül, hogy bármi más telepítve lenne, mint a Node, és telepítse. A Zinnector® előzetesen ellenőrzi a projektet azzal a hellyel szemben, amelyre telepíteni készül — PHP-verzió, lemez, fájlszám —, és még a leküldés előtt figyelmeztet, nem pedig utána. Emellett bejelentkezik, felsorolja a webhelyeket, telepít, kezeli a domaineket és a DNS-t, olvassa a levelezési szolgáltatásokat, biztonsági mentéseket készít, engedélyezési listán szereplő WP-CLI-t futtat, naplókat kötet és tömeges műveleteket hajt végre. Ingyenes, MIT-licences, és ugyanerre a nyilvános API-ra épül.
Kezeld a webhelyeket, domaineket, DNS-rekordokat, postafiókokat és csomagokat infrastruktúra-kódként. A terraform apply kiépíti a tárhelyet, így a környezeteid reprodukálhatóvá és áttekinthetővé válnak a senki által le nem írt kattintássorozatok helyett.
Generált dokumentáció, amelyet közvetlenül a böngészőből olvashatsz és hívhatsz, és amely pontosan leírja a szerver által megvalósított végpontokat – mivel mindkettő ugyanabból a specifikációból származik.
A platform mögött egy robusztus eseményhálózat áll: minden állapotváltozás eseményt ír a Postgres tranzakcionális kimenő üzenetsorába az adatbázis-módosítással atomi módon, és egy továbbító közzéteszi azt a NATS JetStream rendszerben. Az események típusosak és verziózottak – site.deployed, order.paid, invoice.overdue, backup.completed, abuse.flagged, trial.ending és a többi.
Regisztráljon egy végpontot WebhookSubscription-ként, és válassza ki, hogy milyen eseménytípusokat fogadjon. Egyetlen adatfolyam szolgálja ki az értesítéseket, az analitikát, az automatizálásokat és az Ön integrációját is – Ön pontosan ugyanazokat az eseményeket használja fel, mint mi.
Minden kézbesítés HMAC-aláírással van ellátva, így mielőtt intézkedne, ellenőrizheti, hogy valóban tőlünk származik-e.
A sikertelen kézbesítések exponenciális hátráltatással (backoff) újrapróbálásra kerülnek, és minden egyes kísérlet WebhookDelivery-ként rögzítésre kerül. A kézbesítéseket a vezérlőpultról ellenőrizheti és újraindíthatja, ahelyett, hogy az ügyfélszolgálatnak írna e-mailt arról, hogy mit küldtünk.
A folyamat szándékosan legalább egyszeri (at-least-once), ahelyett hogy pontosan egyszeri (exactly-once) próbarna lenni. Egy közzététel közben leálló továbbító (relay) igénylési bérlete letelik, eseményei pedig újra közzétételre kerülnek. A borítóazonosító (envelope id) szerinti duplikációmentesítéssel a fogyasztó felépítéséből adódóan helyes lesz.
Az API csak a fejlesztői történet fele. A másik fele a kiadás.
A platformot üzemeltetett MCP-szerverként tesszük elérhetővé: ez egy vékony protokoll-adapter a motor API-ján, amely újrafelhasználja az azonos műveleti katalógust, az RBAC-t és a naplózási nyomvonalat. Csatlakoztassa a Claude Code, Cursor, ChatGPT, Claude Desktop vagy bármely MCP-képes klienst egyszer, és az API-hoz adott minden funkció automatikusan elérhetővé válik számítógépén.
Az ügynök három dolgot kap: Eszközöket (ugyanazokat az API-végpontokat, nincs eltérő párhuzamos logika), Erőforrásokat (írásvédett webhely-állapot, konfiguráció, legfrissebb naplók, metrikák, üzemidő és Tudásbázis-cikkek, hogy valós adatok alapján diagnosztizáljon a cselekvés előtt) és Utasításokat (közzétett munkafolyamat-sablonokat, mint például „webhely diagnosztizálása” vagy „migráció előkészítése”).
A biztonság ugyanolyan történet, mint az azonosítás: OAuth 2.1, a szervezetünkhöz kötött tokenek és RBAC jogosultságok érvényesített sorszintű biztonsággal, eszközönkénti hatókörrel és visszavonhatósággal, a produkciótól elválasztott homokozóval. A romboló műveletek – törlés, felfüggesztés, számlázás, nagy összegű kiadás – kifejezett jóváhagyást vagy emberi jóváhagyási házirendet igényelnek. A sebességhatárok és a kiadási limitek korlátozzák az AI által indított fizetős műveleteket, és minden egyes MCP-hívást naplóznak a identitással, az eszközzel, az argumentumokkal és az eredménnyel együtt.
Mi a protokoll támogatását választjuk az egyes alkalmazások egyenkénti integrálása helyett, ami azt jelenti, hogy szabadon megváltoztathatja az Ön által használt mesterséges intelligencia eszközöket anélkül, hogy a tárhely-integrációján is változtatnia kellene.
Igen — ez ugyanaz a motor API, publikusan és megerősítve. A vezérlőpult, az adminisztrációs konzol, a CLI, a Terraform szolgáltató, az MCP-szerver és a webhookok mind egyetlen felületet használnak, ami az oka annak, hogy az API nem marad le a panel mögött.
Igen. A homokozókulcsok külön kerülnek kiadásra a éles kulcsoktól, és teszt módban futnak: nincs valós számlázás és nincs valós kiépítés. Irányítsa a CI-t a homokozó hitelesítési adataira, és hajtsa végre biztonságosan a teljes kérés-válasz ciklust.
Küldjön egy Idempotency-Key fejlécet a POST kérésében. Az ismétlési rekord a véglegesítéskor (commit) íródik, nem pedig menet közben, így az újraküldés soha nem játszhat vissza gyorsítótárazott sikeres választ olyan sorra, amely nem véglegesítődött ténylegesen, és a sikertelen kérés azonnal felszabadítja a zárolását, hogy a kijavított újraküldést ne tartsa vissza. A webhook kézbesítés kialakításánál fogva legalább egyszeri (at-least-once) — iktassa ki a duplikációkat a borítékazonosító (envelope id) alapján a saját oldalán.
Ma mégsem. Az API-kulcsok szervezetenként kerülnek kiadásra, így több ügyfélszervezetet átölelő integráció mindegyikhez külön kulccsal rendelkezik. A jogosultságok ellenőrzése szintén szervezetenként történik a felhasználói megbízók esetében: a sites.create jogosultság birtoklása az egyik szervezetben nem biztosít hozzáférést egy másik, független szervezetben, bár az az alatt elhelyezkedő alcégekre vonatkozik. Ez szándékos – így egy kompromittált kulcs csak a saját szervezetére és az az alatti alszervezetekre korlátozódik, nem pedig az egész platformra.
A fejlesztői szerepkör magában foglalja a szervezet olvasását, az API-kulcsok kezelését, webhelyek megtekintését és létrehozásást, újraindításukat, gyorsítótáruk ürítését, valamint a jegyek megtekintését és az azokra való válaszadást. Szándékosan nem tartalmazza a számlázási felügyeletet. Ne feledje, hogy a telepítési és az éles környezetbe küldési (push-to-live) jogosultságok nem részei – ha egy csapattagnak szüksége van ezekre, rendeljen hozzá olyan szerepkört, amely tartalmazza őket, ahelyett, hogy feltételezné, hogy a Fejlesztő a legszélesebb körű technikai szerepkör.
A kézbesítések visszalépéses (backoff) módszerrel újrapróbálkoznak, és minden egyes kísérlet WebhookDeliveryként rögzítésre kerül, amelyet megvizsgálhat. A forrásoldalon az események egy tranzakciós outboxba íródnak ugyanazon adatbázis-tranzakción belül, mint maga a változás, így semmi sem vész el, amíg egy fogyasztó nem érhető el – a leállt fogyasztó késésbe kerül, de soha nem akasztja meg a előállítót, és a kézbesítéseket a vezérlőpultról bármikor újrapróbálhatja, miután ismét online állapotba került.
Kezdjen egy kártya nélküli 14 napos próbaverziót a Footprint-Free Hosting szolgáltatással – nincs szükség fizetési adatokra, legfeljebb 5 webhely. A fizetős Footprint-Free csomagok havi 6 dollártól indulnak a PBN 5 esetében. Minden csomaghoz 30 napos pénzvisszafizetési garancia, ingyenes migráció és nincs gyártói kötöttség.
Spec-alapú API, generált SDK-k, CLI, Terraform szolgáltató, aláírt webhookok és MCP-szerver – a világszerte több mint 650 000 webhely számára épített tárhelyünkön. Kezdje el a kártya nélküli 14 napos próbaverziót, fizetési adatok nélkül.
Kezdje ingyen