Applications

Enregistrer un produit SaaS dans SaaSes : modèle de tenancy, clé API, webhook.

Créer une Application

Depuis la console : /applications/new. Quatre informations sont demandées :

Nom & description — pour l'humain qui les consulte.
Slug — identifiant URL-safe, unique dans votre Organisation, immuable.
Modèle de tenancy — voir Concepts. Immuable après création.
Webhook (optionnel) — URL où SaaSes enverra les événements, et un secret pour signer les payloads.

La clé API ne s'affiche qu'une seule fois

Au moment de la création, SaaSes génère une clé du format sk_orgSlug_XXXXXXXX.... Copiez-la immédiatement — elle n'est ensuite plus jamais affichée en clair. Si vous la perdez, utilisez la rotation.

Choisir le bon modèle de tenancy

Le modèle conditionne la forme du routingConfig que vous fournirez pour chaque souscription. Choisissez celui qui correspond à votre architecture actuelle :

TENANT_ID_SINGLE_DB

Le plus courant. Une seule base de données, chaque table contient une colonne tenant_id. Votre app reçoit l'identifiant du tenant via JWT, header, ou claim.

{ "tenantId": "casaride" }

SUBDOMAIN_SINGLE_DB

Chaque tenant a son propre sous-domaine, mais toutes les données sont dans la même base. Vous extrayez le sous-domaine du Host HTTP.

{ "subdomain": "acme", "tenantId": "acme" }

SUBDOMAIN_MULTI_DB

Une base par tenant — pour des contraintes réglementaires ou de performance. Les credentials sont chiffrés au repos avec AES-256.

{
  "subdomain": "acme",
  "databases": [
    { "type": "MAIN",   "url": "jdbc:postgresql://db1.internal/acme_main", "username": "...", "password": "..." },
    { "type": "REPORTS","url": "jdbc:postgresql://db2.internal/acme_reports", "username": "...", "password": "..." }
  ]
}

PATH_PARAM

L'identifiant tenant figure dans le chemin (/t/{tenantId}/...).

{ "tenantId": "acme" }

HEADER

L'identifiant tenant est passé dans un header HTTP custom.

{ "tenantId": "acme", "headerName": "X-Tenant-ID" }

Authentification de l'API de résolution

Votre app utilise la clé API en header :

Authorization: Bearer sk_acme_AbCdEf...

SaaSes hash la clé reçue en SHA-256 et la compare à apiKeyHash pour identifier l'Application. Le résultat est mis en cache 60 secondes côté SaaSes.

Rotation de clé

POST/api/applications/{appSlug}/rotate-api-key

Depuis la fiche de l'Application, cliquez sur Rotate key. L'ancienne clé est invalidée immédiatement (toute requête en cours avec l'ancienne clé reçoit 401). La nouvelle clé est affichée une seule fois.

Faites tourner régulièrement

En production, prévoyez une procédure de rotation au moins annuelle, et immédiatement en cas de fuite suspectée.

Déprécier une Application

Plutôt que de supprimer une Application (impossible si elle a des souscriptions), vous pouvez la passer en statut DEPRECATEDdepuis la page d'édition. Les clés API existantes sont alors rejetées par l'API de résolution.

Précédent← Concepts clés SuivantPlans tarifaires →