Pour les développeurs
Zinn Digital® est une plateforme orientée API. L'API du même moteur qui alimente notre tableau de bord est celle qui vous est offerte — versionnée, axée sur les spécifications et documentée à 100 % dès la compilation, avec des SDK générés, une CLI, un fournisseur Terraform, des webhooks signés et un serveur MCP en prime. Quels que soient vos outils de travail — un terminal, un pipeline, un fichier d'état ou un agent IA — la plateforme y répond.
La plupart des hébergeurs ajoutent une API à un panneau de contrôle après coup, et cela se voit : la moitié des fonctionnalités du panneau n'en sortent jamais. Nous avons conçu les choses dans l'autre sens. 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 du moteur. Si vous pouvez le faire dans le panneau, vous pouvez le faire par le code.
La spécification OpenAPI fait foi, et aucun point de terminaison n'est déployé s'il n'y figure pas. C'est cette règle unique qui garantit que l'API publique est entièrement documentée dès la phase de compilation et non plus tard : il n'y a pas de zone d'ombre, car un point de terminaison non documenté ne peut pas exister.
Documentation de référence interactive, les quatre SDK clients, une grande partie de la CLI et le squelette 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 ne courez plus après une documentation qui s'est éloignée de l'implémentation.
Les points de terminaison se trouvent sous /v1 avec une politique de dépréciation publiée et un journal des modifications. Vous êtes prévenu par écrit avant qu'un changement n'intervienne, plutôt que de le découvrir lors d'un échec de compilation.
Des tests de contrat d'implémentation par rapport aux spécifications et un linting OpenAPI s'exécutent à chaque modification. Toute divergence entre le code et le contrat fait échouer la compilation — la spécification à partir de laquelle vous générez votre client est donc celle que le serveur respecte réellement.
Deux portes d'entrée, un seul et même principe sous-jacent. Quelle que soit celle que vous utilisez, les mêmes contrôles d'autorisation et la même isolation au niveau de la base de données s'appliquent.
Les clés ont le format zdk_<mode>_<prefix>_<secret>. Seul un hachage SHA-256 du secret est stocké : nous ne pouvons pas vous réafficher une clé après son émission, et personne n'ayant accès à notre base de données ne le peut non plus. Les clés disposent de périmètres, peuvent être révoquées et sont émises par organisation plutôt que par personne.
Les clés de bac à sable sont distinctes des clés de production et fonctionnent en mode bac à sable : pas de facturation réelle, pas de provisionnement réel. Vos tests d'intégration peuvent solliciter l'API sans dépenser d'argent ni créer de serveurs.
Les sessions utilisateur s'authentifient avec des JWT émis par Keycloak, vérifiés par rapport à la clé publique du domaine, et se résolvent au même objet Principal qu'une clé d'API. Les points de terminaison contrôlent l'accès à l'aide de clés de permission granulaires telles que sites.create ou apikeys.manage, vérifiées par organisation — une permission dans une organisation n'accorde aucun accès dans une autre organisation distincte, bien qu'elle s'applique aux organisations qui y sont imbriquées.
Chaque requête de locataire s'exécute dans une transaction avec le périmètre d'organisation Postgres défini à partir du principal, de sorte que l'isolation est garantie par la base de données, et non par un filtre ORM que l'on pourrait oublier. Le filtre du queryset reste présent en tant que défense en profondeur.
Il est facile de faire belle impression avec une API dans un fichier README, mais il est difficile de la faire tenir sous un trafic réel. Ce sont ces aspects qui nous ont donné du fil à retordre, car ce sont eux qui font planter les intégrations à trois heures du matin.
Un détail qui mérite d'être souligné, car il façonne le comportement du traitement en masse : un code 409 en cas de domaine dupliqué répond à « cet hote est-il hébergé ici ? » pour n'importe quel locataire, ce qui constitue un oracle d'énumération et un réel risque de désanonymisation contre Footprint-Free. Limiter la création de sites aurait été une solution de facilité qui aurait carrément cassé le produit de provisionnement en masse. Seules les tentatives de doublons de domaine rejetées sont comptabilisées dans le budget, par principal. Les créations réussies ne sont jamais imputées dessus — vous pouvez donc provisionner en masse toute la journée, et le probing s'arrête presque immédiatement.
Trois consommateurs de la même spécification, pour trois manières de travailler différentes.
Généré pour TypeScript, Python, PHP et Go, en suivant les spécifications afin qu'un nouvel endpoint soit disponible dans votre langage sans attendre l'écriture manuelle d'un wrapper.
Créez un site WordPress, exécutez-le localement sans rien d'autre d'installé que Node, et déployez-le. Zinnector® vérifie votre projet en amont 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 un push plutôt qu'après. Il permet également de se connecter, de lister des sites, de déployer, de gérer les domaines et le DNS, de lire les services de messagerie, d'effectuer des sauvegardes, d'exécuter des commandes WP-CLI autorisées, de suivre les journaux en direct et de déclencher des opérations groupées. Gratuit, sous licence MIT et basé sur cette même API publique.
Gérez les sites, domaines, enregistrements DNS, boîtes aux lettres et abonnements en tant qu'infrastructure sous forme de code. terraform apply provisionne l'hébergement, et vos environnements deviennent reproductibles et vérifiables au lieu d'être une suite de clics que personne n'a notée.
Documentation générée que vous pouvez consulter et appeler directement depuis le navigateur, décrivant exactement les points de terminaison mis en œuvre par le serveur, car les deux proviennent de la même spécification.
Sous la plateforme se trouve un système d'événements robuste : chaque changement d'état écrit un événement dans une table de messagerie transactionnelle dans Postgres, de manière atomique avec la modification de la base de données, et un relais le publie vers NATS JetStream. Les événements sont typés et versionnés : site.deployed, order.paid, invoice.overdue, backup.completed, abuse.flagged, trial.ending et les autres.
Enregistrez un point de terminaison en tant que WebhookSubscription et choisissez les types d'événements qu'il reçoit. Un flux unique alimente les notifications, les analyses, les automatisations et votre intégration : vous consommez exactement les mêmes événements que nous.
Chaque livraison est signée par HMAC afin que vous puissiez vérifier qu'elle provient bien de nous avant de l'exécuter.
Les échecs de livraison sont réessayés avec une temporisation exponentielle et chaque tentative est enregistrée en tant que WebhookDelivery. Vous pouvez inspecter et rejouer les livraisons depuis le tableau de bord au lieu d'envoyer un e-mail au support pour demander ce que nous avons envoyé.
Le pipeline fonctionne volontairement en mode au moins une fois plutôt que de prétendre garantir l'unicité. Un relais qui s'arrête en plein milieu d'une publication voit son bail d'exclusivité expirer et ses événements republiés. Effectuez une déduplication sur l'identifiant de l'enveloppe et votre consommateur sera correct par construction.
Une API ne représente que la moitié de l'histoire pour un développeur. L'autre moitié, c'est le déploiement.
Nous exposons la plateforme sous forme de serveur MCP hébergé : un adaptateur de protocole léger s'appuyant sur l'API du moteur qui réutilise à l'identique le 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 lui devient automatiquement accessible.
L'agent dispose de trois éléments : des Outils (les mêmes points de terminaison d'API, sans logique parallèle susceptible de dériver), des Ressources (santé du site en lecture seule, configuration, journaux récents, métriques, temps de disponibilité et articles de la base de connaissances, afin qu'il pose un diagnostic à l'aide de 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é repose sur les mêmes principes que l'authentification : OAuth 2.1, jetons liés à votre organisation et permissions RBAC avec sécurité au niveau des lignes appliquée, délimitées et révocables par outil, sandbox séparée de la production. Les actions destructrices — suppression, suspension, facturation, dépenses importantes — requièrent 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 fait l'objet d'un journal d'audit consignant l'identité, l'outil, les arguments et le résultat.
Nous soutenons le protocole plutôt que d'intégrer chaque application une par une, ce qui signifie que votre choix d'outils d'IA peut changer sans que votre intégration d'hébergement n'ait besoin de changer avec lui.
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 seule et même interface, ce qui explique pourquoi l'API n'a pas de retard par rapport au panneau.
Oui. Les clés de bac à sable sont émises séparément des clés de production et fonctionnent en mode test : pas de facturation réelle ni de provisionnement réel. Pointez votre CI vers les identifiants du bac à sable et testez le cycle complet des requêtes et des réponses en toute sécurité.
Envoyez un Idempotency-Key lors de votre requête POST. L'enregistrement de relecture est écrit au moment de la validation 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 réellement été validée, et une requête qui échoue libère immédiatement son verrou afin que votre tentative corrigée ne soit pas bloquée. La livraison des webhooks est conçue pour être effectuée au moins une fois — dédupliquez sur l'identifiant d'enveloppe 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 permissions sont également vérifiées par organisation pour les principaux utilisateurs : détenir sites.create dans une organisation ne donne aucun accès dans une autre organisation distincte et non liée, bien que cela s'applique aux organisations imbriquées sous celle-ci. C'est délibéré : cela confine une clé compromise à sa propre organisation et aux sous-organisations qui en dépendent, et non à l'ensemble de la plateforme.
Le rôle de développeur couvre la lecture des organisations, la gestion des clés API, l'affichage et la création de sites, leur redémarrage, le vidage de leur cache, ainsi que l'affichage et la réponse aux tickets. Il exclut délibérément le contrôle de la facturation. Notez que les autorisations de déploiement et de mise en ligne n'en font pas partie. Si un membre de l'équipe en a besoin, attribuez-lui un rôle qui les inclut au lieu de supposer que Développeur est le rôle technique le plus étendu.
Les livraisons sont réessayées avec temporisation exponentielle et chaque tentative est enregistrée en tant que WebhookDelivery que vous pouvez inspecter. En amont, les événements sont écrits dans une table de messagerie transactionnelle au sein de la même transaction de base de données que la modification elle-même, de sorte qu'aucun élément n'est perdu lorsqu'un consommateur est indisponible : un consommateur en panne accuse un retard, il ne bloque jamais le producteur, et vous pouvez rejouer les livraisons depuis le tableau de bord une fois le service rétabli.
Commencez un essai gratuit de 14 jours de Footprint-Free Hosting sans carte de crédit — aucun détail de paiement requis, jusqu'à 5 sites. Les offres payantes de Footprint-Free commencent à 6 $/mois pour PBN 5. Chaque formule s'accompagne d'une garantie de remboursement de 30 jours, de migrations gratuites et d'aucune dépendance vis-à-vis d'un fournisseur.
API orientée spécification, 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 650 000 sites dans le monde. Commencez un essai de 14 jours sans carte bancaire, sans coordonnées de paiement.
Commencer gratuitement