Organisations, applications et environnements

Organisation = équipe et facturation ; application = workflows et clés API, en live ou sandbox. Comprendre cette structure évite la plupart des surprises.

#Les deux niveaux

Organisation est votre compte. Elle possède :

• Votre équipe et leurs rôles
• Votre solde de facturation et vos factures
• Votre journal d'audit
• Toutes vos applications

Application est un espace de travail à l'intérieur de l'organisation. Elle possède :

• Ses propres workflows
• Ses propres clés API
• Ses propres endpoints de webhook
• Sa propre politique de rétention des données
• Ses propres produits, là où l'activation des produits par application a été déployée. Voir les produits et ce qu'ils incluent
• Deux environnements : Production et Bac à sable

Changez d'application depuis la carte d'application en haut de la barre latérale. Le changement s'applique immédiatement. Le même menu ouvre Paramètres de l'application et Créer une application.

#Pourquoi c'est plus important que ça n'en a l'air

Presque tous les signalements du type « j'ai changé ça et rien ne s'est passé » se résolvent avec cette structure :

• Vous avez modifié un workflow dans l'application A alors que vos sessions tournent sous l'application B.
• Vous avez ajouté un endpoint de webhook à une application en attendant des événements d'une autre.
• Vous regardez Bac à sable alors que votre trafic passe en Production, ou l'inverse.
• Vous appelez avec une clé d'une application différente de celle de la ressource que vous ciblez, et vous obtenez un 404 ou un 403 pour quelque chose qui existe pourtant clairement.

Avant de déboguer quoi que ce soit d'autre, confirmez l'application. Voir erreurs API et leur signification.

#Production et Bac à sable sont des environnements distincts

Les nouvelles applications sont en Production. Les tests se font en Bac à sable : l'application de test partagée de votre organisation, avec ses propres données et ses propres clés. Passez de l'un à l'autre avec le sélecteur Production / Bac à sable sous le nom de l'application dans la barre latérale.

Les vérifications, les clés API, les webhooks et les listes sont séparés dans chaque environnement. L'image de marque est partagée, et les workflows se construisent une fois et peuvent être copiés d'un environnement à l'autre. Cette séparation est le but recherché : le trafic de test et les données de production ne se mélangent jamais, et une clé sandbox ne peut pas accidentellement dépenser de vrais crédits. Voir tester en sandbox.

#Combien d'applications faut-il avoir ?

La plupart des équipes commencent avec une seule, qui vous donne déjà Production et Bac à sable. Au-delà, séparez selon ce qui a besoin de sa propre configuration ou de sa propre isolation :

• Par produit, quand des produits différents ont besoin de workflows et de points de terminaison webhook différents.
• Par environnement de préproduction, si un seul Bac à sable ne vous suffit pas.
• Par marque, si vous proposez la vérification sous plusieurs marques avec des styles différents.
• Par politique de rétention, puisque la rétention est configurée par application.

Ce qui ne se sépare pas par application : votre solde, qui est au niveau de l'organisation. Chaque application puise dans les mêmes crédits.

#Créer des applications supplémentaires

Ouvrez la carte d'application en haut de la barre latérale et choisissez Créer une application, puis saisissez un Nom de l'application (là où les produits par application ont été déployés, vous choisissez aussi à quoi elle sert). Si l'option est manquante, ou si vous devez en créer une via l'API plutôt que via la console, c'est une question de permission au niveau du compte à poser au support plutôt qu'à contourner.

#Plusieurs organisations

Une même personne peut appartenir à plusieurs organisations, et passe de l'une à l'autre depuis le menu de l'organisation en haut de la barre latérale, où apparaissent aussi les invitations en attente. Créer vous-même plus d'une organisation est réservé aux comptes revendeurs (contactez le support pour l'activer), et il n'existe aucun moyen de créer des sous-organisations ou des sous-comptes sous la vôtre. Si vous servez plusieurs de vos propres clients, la structure prise en charge est une application par client au sein de votre unique organisation : chaque application a ses propres workflows, sa marque, ses clés d'API, ses résultats et ses rapports d'utilisation, totalement isolés des autres, tandis que la facturation reste au niveau de votre organisation.

#Revendre Didit

Si vous voulez intégrer Didit à votre propre produit et le facturer à vos clients, c'est le modèle revendeur. Voici comment il fonctionne, dans les termes que le support donne à tous ceux qui posent la question :

• Crédit prépayé. Un achat initial minimum de 5 000 USD, prépayé, sur un accord d'un an. Le crédit n'expire jamais, il se situe au niveau de votre organisation et se consomme sur l'ensemble des clients finaux que vous intégrez, et il comporte une remise de volume qui augmente avec le montant.
• Le tableau de bord, c'est vous qui le construisez. Vous intégrez l'API Didit dans votre propre front-end et vos clients y gèrent leurs workflows, leur marque et leurs rôles. Didit ne fournit pas de copie en marque blanche de la Business Console ; les écrans de vérification vus par vos utilisateurs finaux peuvent porter votre marque (voir marque blanche), la console non.
• Votre marge vous appartient. Vous fixez le prix payé par vos clients. Didit vous facture par fonctionnalité terminée aux prix unitaires fixés pour la durée de l'accord.
• Ce n'est pas un programme de partenaires locaux. Didit assure les démos, l'onboarding et le support directement avec les clients et ne recherche pas de partenaires de distribution ou d'intégration.

Si vous préférez ne pas gérer la revente, utilisez plutôt l'option parrainage : dans la Business Console, ouvrez Paramètres → Parrainez et gagnez, récupérez votre lien et partagez-le. Vous touchez une commission de 10 % sur chaque dépôt en espèces effectué par une organisation parrainée, pendant 36 mois à compter de son premier dépôt, utilisable en crédit Didit ou versée par virement bancaire une fois mûrie, sans obligation de livraison ni de support. Vous pouvez construire et tester votre intégration sur l'offre gratuite avant de vous engager dans l'une ou l'autre voie.

#Supprimer une application

La suppression définitive d'une application n'est pas encore disponible : Paramètres de l'application comporte une Zone de danger, mais elle indique que la suppression est indisponible et ne supprime rien. Vos options en attendant :

• Cessez de l'utiliser. Renommez-la (par exemple acme-old) pour que personne ne la choisisse par erreur, et révoquez ses clés API sous Développeurs → Clés API.
• Effacez ses données client. Les données de vérification suivent la politique de rétention et les règles de suppression propres à ces données, pas le cycle de vie de l'application : supprimez les données explicitement. Voir supprimer des sessions et des données personnelles.
• Repartez de zéro. Le support peut supprimer l'organisation entière pour que vous puissiez en créer une nouvelle : c'est un dernier recours, puisque l'équipe, le solde et l'historique disparaissent avec elle.

#Tout est attribuable

Chaque modification enregistre l'application à laquelle elle appartenait, dans le journal d'audit. C'est ce qui rend une structure multi-application auditable et pas seulement bien rangée. Voir utiliser les journaux d'audit.