Pour les développeurs
Zinn Digital® est une plateforme axée sur les API (API-first). L’API de moteur qui alimente notre tableau de bord est exactement celle dont vous bénéficiez : versionnée, basée sur des spécifications et documentée à 100 % au moment de la compilation, avec des SDK générés, une CLI, un fournisseur Terraform, des webhooks signés et un serveur MCP en complément. Quel que soit l’outil que vous utilisez pour travailler — un terminal, un pipeline, un fichier d’état ou un agent d’IA —, la plateforme y répond.
La plupart des hébergeurs greffent une API sur un panneau de configuration après coup, et cela se voit : la moitié des fonctionnalités du panneau ne sont jamais intégrées. Nous avons procédé exactement dans le sens inverse. Le tableau de bord, la console d’administration, la CLI, le fournisseur Terraform, le serveur MCP et vos propres intégrations consomment tous la même API de moteur. Si vous pouvez le faire dans le panneau, vous pouvez le faire dans le code.
La spécification OpenAPI constitue la source unique de vérité, et aucun point de terminaison n’est déployé s’il n’y figure pas. Cette règle unique permet à l’API publique d’être entièrement documentée dès la compilation plutôt qu’ultérieurement — il n’y a aucune zone d’ombre non documentée, car un point de terminaison non documenté ne peut tout simplement pas exister.
La documentation de référence interactive, les quatre SDK clients, une grande partie de la CLI et la structure du fournisseur Terraform sont tous générés à partir de cette unique spécification. Une seule source, de nombreux artefacts, toujours synchronisés — vous n’avez jamais à courir après une documentation qui s’est éloignée de l’implémentation.
Les points de terminaison se trouvent sous /v1 avec une politique d’obsolescence publiée et un journal des modifications. Vous êtes prévenu par écrit avant qu’un changement ne survienne, plutôt que de le découvrir lors de l’échec d’une compilation.
Les tests de contrat d’implémentation par rapport aux spécifications et le linting OpenAPI sont exécutés à chaque modification. Tout écart entre le code et le contrat entraîne l’échec de la compilation — ainsi, la spécification à partir de laquelle vous générez votre client est celle que le serveur respecte réellement.
Deux voies d’accès, un principe uniforme derrière elles. Quelle que soit celle que vous utilisez, les mêmes contrôles d’autorisations et la même isolation au niveau de la base de données s’appliquent.
Les clés se présentent sous la forme zdk_<mode>_<prefix>_<secret>. Seul un hachage SHA-256 du secret est stocké — nous ne pouvons plus vous montrer une clé après sa création, et personne ayant accès à notre base de données ne le peut non plus. Les clés comportent des portées, peuvent être révoquées et sont délivrées par organisation plutôt que par personne.
Les clés sandbox sont distinctes des clés de production et fonctionnent en mode sandbox : aucune facturation réelle, aucun provisionnement réel. Vos tests d’intégration peuvent solliciter l’API de manière intensive sans dépenser d’argent ni créer de serveurs.
Les sessions utilisateur s’authentifient à l’aide de JWT émis par Keycloak, vérifiés par rapport à la clé publique du domaine (realm), et correspondent au même objet Principal qu’une clé d’API. Les points de terminaison sont contrôlés par des clés d’autorisation granulaires telles que sites.create ou apikeys.manage, vérifiées par organisation — une autorisation dans une organisation n’accorde aucun accès dans une organisation distincte et non liée, bien qu’elle s’applique aux organisations imbriquées sous celle-ci.
Chaque requête de locataire s’exécute dans une transaction avec la portée de l’organisation Postgres définie à partir du principal, de sorte que l’isolation est appliquée par la base de données, et non par un filtre ORM que quelqu’un pourrait oublier. Le filtre queryset reste en place en tant que défense en profondeur.
Il est facile de donner fière allure à une API dans un fichier README, mais difficile de lui assurer un comportement optimal sous un trafic réel. Ce sont ces parties qui nous ont demandé le plus d’efforts, car ce sont elles qui font échouer les intégrations à trois heures du matin.
Un détail mérite d’être souligné, car il façonne le fonctionnement des opérations en bloc : une erreur 409 sur un domaine en double répond à la question « ce nom d’hôte est-il hébergé ici ? » pour n’importe quel locataire, ce qui constitue un oracle d’énumération et un risque réel de désanonymisation pour Footprint-Free. Brider la création de sites aurait été la solution de facilité et aurait totalement détruit le produit de provisionnement en masse. Au lieu de cela, seules les tentatives rejetées de domaines en double sont soumises à un quota, par entité principale. Les créations réussies ne sont jamais imputées à ce quota — vous pouvez donc provisionner en bloc toute la journée, et les tentatives de sondage s’arrêtent presque immédiatement.
Trois consommateurs d’une même spécification, pour trois méthodes de travail différentes.
Généré pour TypeScript, Python, PHP et Go, en suivant la spécification afin qu’un nouveau point de terminaison arrive dans votre langage sans attendre un wrapper écrit à la main.
Générez la structure d’un site WordPress, exécutez-le localement avec pour seule installation Node, et déployez-le. Zinnector® vérifie au préalable votre projet par rapport à l’emplacement sur lequel vous vous apprêtez à déployer — version de PHP, disque, nombre de fichiers — et vous avertit avant d’effectuer le push plutôt qu’après. Il se connecte également, liste les sites, déploie, gère les domaines et le DNS, lit les services de messagerie, effectue des sauvegardes, exécute les commandes WP-CLI autorisées, suit les journaux et lance des opérations groupées. Gratuit, sous licence MIT et conçu sur cette même API publique.
Gérez les sites, les domaines, les enregistrements DNS, les boîtes aux lettres et les forfaits en tant qu’infrastructure as code. terraform apply provisionne l’hébergement, et vos environnements deviennent reproductibles et vérifiables plutôt qu’une suite de clics que personne n’a documentée.
Une documentation générée que vous pouvez lire et appeler depuis le navigateur, décrivant exactement les points de terminaison implémentés par le serveur — car tous deux proviennent de la même spécification.
Derrière la plateforme se trouve une dorsale d’événements durable : chaque changement d’état écrit un événement dans une boîte d’envoi transactionnelle dans Postgres, de manière atomique avec la modification de la base de données, et un relais le publie sur NATS JetStream. Les événements sont typés et versionnés — site.deployed, order.paid, invoice.overdue, backup.completed, abuse.flagged, trial.ending et le reste.
Enregistrez un point de terminaison en tant que WebhookSubscription et choisissez les types d’événements qu’il reçoit. Un flux unique alimente aussi bien les notifications, les analyses, les automatisations que votre intégration — vous consommez les mêmes événements que nous.
Chaque envoi est signé avec HMAC afin que vous puissiez vérifier qu’il provient bien de nous avant d’agir.
Les distributions ayant échoué font l’objet d’une nouvelle tentative avec temporisation, et chaque tentative est enregistrée sous la forme d’un WebhookDelivery. Vous pouvez inspecter et rejouer les distributions depuis le tableau de bord au lieu d’envoyer un e-mail à l’assistance pour savoir ce que nous avons envoyé.
Le pipeline fonctionne délibérément selon le principe « au moins une fois » plutôt que de prétendre fonctionner « exactement une fois ». Un relais qui s’interrompt en cours de publication voit son bail de revendication expirer et ses événements sont republiés. Dédupliquez sur l’ID de l’enveloppe et votre consommateur sera correct par conception.
Une API ne représente que la moitié de l’histoire d’un développeur. L’autre moitié, c’est le déploiement.
L’API est une porte. Voici les quatre autres, et chacune d’elles est incluse dans le forfait plutôt que d’être vendue sous forme d’offre développeur.
VS Code dans le navigateur, ouvert depuis la page du site dans le tableau de bord, modifiant les fichiers réels de ce site avec git intégré et l’ensemble de l’éditeur au sein du même environnement isolé CageFS que votre accès SFTP. Il modifie le site EN DIRECT — il n’y a pas de copie de préproduction intermédiaire, de sorte qu’un fichier que vous enregistrez est public dès qu’il est écrit, bien qu’un fichier statique puisse continuer à être servi depuis le cache CDN pendant un délai pouvant atteindre quatre heures.
Gratuit, sous licence MIT et basé sur cette même API publique. Générez la structure d’un site WordPress, exécutez-le sur votre propre machine, pré-vérifiez-le par rapport à l’emplacement sur lequel vous êtes sur le point de déployer — version de PHP, disque, nombre de fichiers — et déployez. Nécessite Node 24 ou une version plus récente.
Un catalogue unique d’outils, afin que le client d’IA que vous utilisez déjà puisse intervenir sur vos sites via la même API et les mêmes autorisations que le tableau de bord. Le serveur auquel votre propre client se connecte est exactement celui qui est relié à l’éditeur web. En lecture seule, sauf indication contraire de votre part.
Le travail pour vos clients ne nécessite pas votre mot de passe. Invitez quelqu’un par adresse e-mail et cette personne n’aura accès qu’à un seul site : elle se connecte sous sa propre identité, avec le rôle de lecteur, d’éditeur ou de gestionnaire, et tout autre site renvoie une erreur 404 avant même l’exécution d’un quelconque gestionnaire — une stratégie de sécurité au niveau des lignes Postgres et un cloisonnement au niveau de la requête, et non une simple vérification. Le propriétaire du compte accorde et révoque cet accès en un seul clic, avec prise d’effet dès la requête suivante.
Nous exposons la plateforme sous la forme d’un serveur MCP hébergé : un adaptateur de protocole léger sur l’API du moteur qui réutilise le même catalogue d’actions, le RBAC et la piste d’audit. Connectez Claude Code, Cursor, ChatGPT, Claude Desktop ou tout client compatible MCP une seule fois, et chaque fonctionnalité que nous ajoutons à l’API devient automatiquement disponible pour lui.
L’agent dispose de trois éléments : des Outils (les mêmes points de terminaison d’API, aucune logique parallèle susceptible de diverger), des Ressources (état du site en lecture seule, configuration, journaux récents, métriques, temps de disponibilité et articles de la base de connaissances, afin qu’il établisse un diagnostic avec des données réelles avant d’agir) et des Invites (des modèles de flux de travail publiés tels que « diagnostiquer ce site » ou « préparer une migration »).
La sécurité suit la même logique que l’authentification : OAuth 2.1, jetons liés à votre organisation et autorisations RBAC avec sécurité au niveau des lignes appliquée, délimitées et révocables par outil, bac à sable séparé de la production. Les actions destructrices — suppression, suspension, facturation, dépenses importantes — nécessitent une confirmation explicite ou une politique d’approbation humaine. Des limites de débit et des plafonds de dépenses encadrent les actions payantes déclenchées par l’IA, et chaque appel MCP est consigné dans le journal d’audit avec l’identité, l’outil, les arguments et le résultat.
Nous prenons en charge le protocole plutôt que d’intégrer chaque application individuellement, ce qui signifie que votre choix d’outils d’IA peut changer sans que votre intégration d’hébergement ne doive être modifiée.
Oui — il s’agit de la même API de moteur, publiée et renforcée. Le tableau de bord, la console d’administration, la CLI, le fournisseur Terraform, le serveur MCP et les webhooks sont tous des consommateurs d’une même surface, c’est pourquoi l’API ne prend aucun retard sur le panneau.
Oui. Les clés Sandbox sont émises séparément des clés de production et fonctionnent en mode test : aucune facturation réelle et aucun provisionnement réel. Pointez votre CI vers les identifiants sandbox et testez le cycle complet de requête et de réponse en toute sécurité.
Envoyez une Idempotency-Key lors de votre POST. L’enregistrement de relecture est écrit lors du commit plutôt qu’en ligne, de sorte qu’une nouvelle tentative ne peut jamais rejouer un succès mis en cache pour une ligne qui n’a pas été réellement validée, et une requête qui échoue libère immédiatement son verrou afin que votre nouvelle tentative corrigée ne soit pas retardée. La distribution des webhooks est conçue pour être effectuée au moins une fois (at-least-once) — dédupliquez selon l’envelope id de votre côté.
Pas aujourd’hui. Les clés d’API sont émises par organisation, de sorte qu’une intégration couvrant plusieurs organisations clientes détient une clé pour chacune d’elles. Les autorisations sont également vérifiées par organisation pour les entités utilisateurs : détenir sites.create dans une organisation n’accorde aucun accès dans une organisation distincte et non liée, bien que cela s’applique aux organisations imbriquées sous celle-ci. Cela est délibéré — cela confine une clé compromise à sa propre organisation et aux sous-organisations situées en dessous, et non à l’ensemble de la plateforme.
Le rôle dev couvre la lecture au niveau de l’organisation, la gestion des clés API, l’affichage et la création de sites, leur redémarrage, la purge de leur cache, ainsi que la consultation des tickets et la réponse à ceux-ci. Il exclut délibérément le contrôle de la facturation. Notez que les autorisations de déploiement et de push-to-live n’en font pas partie — si un membre de l’équipe en a besoin, attribuez-lui un rôle qui les inclut plutôt que de supposer que Developer est le rôle technique le plus large.
Les distributions font l’objet de nouvelles tentatives avec un délai exponentiel (backoff) et chaque tentative est enregistrée sous la forme d’un WebhookDelivery que vous pouvez inspecter. En amont, les événements sont écrits dans une boîte d’envoi transactionnelle au sein de la même transaction de base de données que la modification elle-même, de sorte que rien n’est perdu lorsqu’un consommateur est indisponible — un consommateur défaillant prend du retard, mais n’interrompt jamais le producteur, et vous pouvez rejouer les distributions depuis le tableau de bord une fois de retour.
Commencez par un essai de 14 jours sans carte bancaire de l’hébergement Footprint-Free — aucune information de paiement, jusqu’à 5 sites. Les offres payantes Footprint-Free commencent à 6 $/mois pour PBN 5. Chaque forfait comprend une garantie satisfait ou remboursé de 30 jours, des migrations gratuites et aucun engagement auprès d’un fournisseur exclusif.
API conçue selon les spécifications (« spec-first »), SDK générés, CLI, fournisseur Terraform, webhooks signés et serveur MCP — sur l’hébergement que nous avons conçu pour plus de 700 000 sites dans le monde entier. Commencez par un essai de 14 jours sans carte ni coordonnées de paiement.
Commencer gratuitementChacun de ces plugins transforme votre site WordPress en serveur MCP, de sorte que Claude, Cursor, VS Code et d’autres assistants IA peuvent y effectuer de véritables tâches, connectés en tant que vous et limités à ce que vous êtes autorisé à faire.