Documentation développeur

Tutoriel complet : compte développeur, un widget météo sans une ligne de code (manifeste seul), l'installation de test, la publication sur le marketplace — puis la même app avec la CLI, puis avec du code hébergé.

Installer la commande capibara, lier un dossier au projet du portail par une clé de projet, développer en deploy-on-save sur votre organisation de test, lire le journal, créer et publier une version — sans tunnel ni émulateur.

Les URLs llms.txt, llms-full.txt, le Markdown brut par page et l'archive ZIP — pour construire une app Capibara avec l'aide d'un assistant IA.

Chaque champ du manifeste add-on.json : type, contrainte exacte, règles de tarification croisées, erreurs de validation typiques et 3 manifestes complets.

Chaque capability du manifeste, ce qu'elle autorise, quand la demander — et, en un seul endroit, les bornes réelles de l'exécution (temps, tailles, appels, concurrence, disjoncteur) et les erreurs que votre code peut rencontrer.

Votre app ne produit jamais d'HTML : elle renvoie un arbre JSON de composants (le Kit) que Capibara rend avec ses propres composants, à sa charte — page d'app, panneau sur une fiche, widget, page du site public, formulaire.

Comment votre code hébergé s'exécute : `defineApp({ pages, widgets, panels, forms, actions, events, schedules, http })`, le contexte `ctx`, le protocole d'interaction (rendu → Kit, action → effets), les limites et le journal.

Des widgets d'accueil sans page ni code : un template, des champs de config saisis par l'utilisateur, une source de données allowlistée — la plateforme collecte et rend à la charte Capibara.

Le catalogue fermé des scopes qu'une app peut demander (ressources feuilles, jamais un module entier), la phrase que voit l'administrateur, le compte de service sous lequel l'app agit, et « utiliser l'app ».

Ce que votre app peut lire et écrire dans le CRM, la facturation, la boutique, les projets, le planning, les membres du site et la formation — depuis le code hébergé (`ctx.capibara`) ou depuis votre backend (REST), sous les scopes accordés.

Où vivent les données de votre app (chez l’organisation), comment les déclarer, les lire et les écrire, et ce qu’il en advient à la désinstallation.

Ce que votre app peut envoyer, notifier, projeter, indexer ou faire valider chez l’organisation — par les moteurs de Capibara, avec leurs garde-fous et leurs quotas.

Le SDK TypeScript officiel : types du Kit, du manifeste, des scopes et des façades générés depuis les schémas de la plateforme, defineApp + ui, harnais de test local, client API, OAuth PKCE et webhooks — zéro dépendance.

Héberger la logique de votre app chez vous : manifeste, secret et signature des requêtes, createBackend, ce qui reste réservé au code hébergé, paiements, tests, review.

Les deux grants OAuth réels de Capibara — client_credentials serveur-à-serveur et authorization_code + PKCE avec écran de consentement — séquences curl complètes.

Authentification Bearer (clé API, jeton OAuth ou clé de projet), /me, embed-context, les façades par installation, l'API de projet (clé cpk_… de la CLI), les quotas et les conventions d'erreur.

Recevez les événements métier (commande, facture, contact…) des organisations qui utilisent votre app : configuration, signature HMAC, retries, idempotence.

Soumettre en review (portail ou capibara deploy), ce que le build automatisé et la review vérifient, la validation automatique, les motifs de refus, publier, mettre à jour, le kill switch, le retrait de fiche et la fiche marketplace.

Le modèle de prix du manifeste, l'inscription Stripe Connect Express, les 3 paliers de partage chiffrés en euros, les relevés mensuels, les remboursements et la responsabilité fiscale du développeur.