Connexion et sessions renouvelables
Un client sélectionne son compte ShareAI, approuve votre application et revient à JamZY.
Connectez-vous, actualisez la session et déconnectez-vous avec succès.
CONSTRUIRE AVEC SHAREAI
Créez une application de rendez-vous qui connecte les clients à ShareAI, prépare des agendas IA utiles et leur donne le contrôle de leurs dépenses IA.
L'expérience que vous allez construire
JamZY · Rendez-vousChoisissez un rendez-vous. Connectez ShareAI. Arrivez avec un plan.
VOTRE MISE EN ŒUVRE
Trois livrables concrets : connecter le client, préparer son rendez-vous et rendre l'intégration prête à être vérifiée.
Un client sélectionne son compte ShareAI, approuve votre application et revient à JamZY.
Connectez-vous, actualisez la session et déconnectez-vous avec succès.
Transformez un objectif de rendez-vous en un agenda et des questions via une demande IA délibérée.
Générez un brouillon ; enregistrer un rendez-vous ne déclenche aucun appel IA.
Expliquez les frais IA optionnels et collectez les vérifications de plateforme nécessaires à la soumission de votre revue.
Chaque plateforme incluse et portée demandée a des vérifications enregistrées.
INTÉGREZ-LE DANS VOTRE ÉDITEUR
Copiez le guide complet avec l'objectif de mise en œuvre, les entrées requises et les vérifications d'acceptation. Gardez les exemples de code, les tableaux et les liens de documentation ensemble.
Prêt pour votre projet, dans le format dont vous avez besoin.
Mis à jour
Vous construirez une connexion que vos clients peuvent comprendre : leur ShareAI compte, un brouillon de préparation IA optionnel, et un chemin clair vers leur rendez-vous.
Où vous travaillerez Votre exemple terminé
Connectez votre application à ShareAI Builder, de l'inscription à une intégration testée prête pour examen. Ce guide utilise JamZY, une petite application de rendez-vous Node.js, pour montrer chaque étape : enregistrer l'application, configurer sa plateforme Web, connecter le ShareAI compte d'un client et envoyer une demande IA autorisée. Appliquez les mêmes étapes à votre propre produit.
| Capacité | Ce que le client accepte | Ce que JamZY démontre |
|---|---|---|
| Connexion avec ShareAI | Une connexion de compte et les informations d'identité que votre application demande. | Une identité client privée à partir des informations utilisateur authentifiées. |
| Payer avec ShareAI · Utilisation IA | Utilisation du compte personnel ou organisationnel sélectionné par le client pour une inférence autorisée. | Un brouillon de préparation de rendez-vous financé par les crédits éligibles de ce compte. |
| Builder majoration | Les frais supplémentaires d'utilisation de l'IA dans le contrat d'application accepté. | Monétisation optionnelle de l'utilisation, après approbation et publication du contrat. |
| Paiements de produits | Un achat particulier présenté dans un ShareAI processus de paiement séparé. | Une extension expliquée dans le guide de paiement. La démonstration de rendez-vous n'implémente pas de processus de paiement. |
Ayez un ShareAI compte, la permission d'utiliser le compte personnel ou organisationnel qui possédera l'application, un callback HTTPS public, un logo, et des pages de confidentialité, de conditions et de suppression de compte fonctionnelles. Pour exécuter l'exemple, utilisez Node.js 22 ou une version plus récente et une adresse HTTPS pour votre application.
Les captures d'écran utilisent les détails d'une application exemple. Les adresses ShareAI dans ce guide sont des adresses de production. Générer une préparation effectue une véritable requête d'IA et peut consommer des crédits ; sélectionner ou enregistrer un rendez-vous de démonstration ne le fait pas. Les vérifications sont effectuées par vos propres tests d'intégration réussis.
Vous pouvez distinguer la connexion au compte, la consommation d'IA, le supplément optionnel et un achat de produit confirmé. Lire ce guide ne nécessite pas de requête payante.
Vous allez créer l'identité du Builder qui possède votre application et ses relations clients.
Où vous travaillerez Console → Programme de création
Builder Program s'ouvre pour le propriétaire prévu et propose Nouvelle application. Une décision d'inscription, une révision de l'application, une révision des informations publiques et une approbation Monetization Gateway sont des étapes distinctes.
Vous donnerez à JamZY son propre enregistrement d'application, afin que son identité, son accès et ses conditions commerciales restent ensemble.
Où vous travaillerez Builder Program → Product → Nouvelle application
Utilisez un site web public accessible pour le profil de l'application. Un site web privé ou uniquement local peut échouer à la validation même si votre rappel de développement est correctement enregistré. La nouvelle application commence comme un brouillon. Vous pouvez continuer à la modifier sans la rendre publique. Son identifiant d'application est différent d'un ID client OAuth ou d'un ID d'abonnement.
JamZY apparaît sous Produit pour le propriétaire prévu. Ne créez pas une application supplémentaire pour chaque plateforme de dispositif.
Vous obtiendrez des options OAuth adaptées à l'endroit où votre application s'exécute et à la personne qui contrôle ses identifiants.
Où vous travaillerez Nouvelle application → Configuration de l'application
Pour un déploiement JamZY que vous gérez vous-même, choisissez le modèle de tarification qui correspond à votre offre : SaaS, application cloud hébergée par le fournisseur, le client paie pour sa propre consommation, et ShareAI pour les requêtes d'IA. Ce sont des réponses d'exemple, pas une exigence pour chaque produit.
| Où l'application s'exécute | Choix OAuth | Où résident les identifiants |
|---|---|---|
| Votre backend hébergé | Le client Web serveur peut utiliser un secret client. PKCE s'applique toujours. | Le secret et les jetons restent sur votre serveur. |
| Application navigateur / SPA | Client Web public avec PKCE. | Aucun secret client intégré. Utilisez une conception de session navigateur ou backend appropriée. |
| Distribution auto-hébergée ou hybride | Client public avec PKCE selon la politique d'intégration. | Ne distribuez pas un secret fournisseur partagé aux installations des clients. |
| Windows, macOS, Linux, Android ou iOS | Un client public pour chaque plateforme activée. | PKCE et stockage sécurisé adapté à la plateforme ; aucun secret intégré. |
L'exemple téléchargeable JamZY utilise délibérément un client Web public avec PKCE, même s'il dispose d'un petit backend. Le serveur garde les jetons hors du stockage du navigateur. Une réponse hébergée par le fournisseur permet un client serveur ; elle ne vous oblige pas à en choisir un.
Vous pouvez revoir les réponses enregistrées sous Informations sur l'application → Configuration de l'application. Les modifications de déploiement peuvent supprimer des secrets clients incompatibles et nécessiter une nouvelle vérification. Examinez cet impact avant de sauvegarder.
Le déploiement enregistré décrit votre architecture réelle. L'option de secret client suit cette réponse ; une option désactivée est une explication de la politique, pas une absence d'identifiant.
Vous fournirez aux clients les détails et politiques du produit dont ils ont besoin avant de décider de se connecter.
Où vous travaillerez Informations sur l'application
Ouvrez Informations sur l'application après le tableau de bord. Parcourez les sections dédiées : détails, configuration de l'application, présentation, image de marque, galerie et révision. Donnez au produit une description utile, un site Web précis et des captures d'écran claires du flux de travail client.
Utilisez l'identité de votre propre application. La marque ShareAI appartient au bouton d'intégration et au matériel explicatif ; elle ne doit pas remplacer le logo de votre produit. Gardez les liens vers la confidentialité, les conditions et la suppression accessibles sans connexion.
Enregistrez les modifications lorsque l'action d'enregistrement flottante apparaît. La proposition d'information publique a sa propre révision ; modifier une proposition approuvée ne remplace pas silencieusement la présentation publique en ligne.
Un visiteur peut comprendre ce que fait JamZY, qui l'exploite et comment demander une suppression. Les détails publics et la configuration du rappel se réfèrent au même produit.
Vous demanderez l'accès que votre expérience de rendez-vous utilise réellement et préciserez son objectif de facturation.
Où vous travaillerez Application → Cas d'utilisation
Dans Cas d'utilisation, activez Connexion avec ShareAI pour la connexion de compte et Pay with ShareAI pour le flux financé par le client que vous souhaitez prendre en charge. Demandez l'accès à Monetization Gateway uniquement si votre produit générera des frais supplémentaires sur l'utilisation de l'IA. Suivez le statut d'approbation affiché dans Console.
| Portée | Pourquoi vous le demanderiez |
|---|---|
openid | Connectez un compte en utilisant son identité à portée client. |
profile / email | Demandez les revendications de profil ou d'email uniquement si votre produit en a besoin. |
inference | Appelez les points de terminaison d'inférence AI pris en charge lorsque la configuration de l'application le permet. |
monetization_gateway | Utilisez l'accord de facturation AI accepté par le client pour l'inférence avec supplément. |
payments | Créez et inspectez les demandes de paiement des clients. Chaque achat nécessite toujours une confirmation. |
Requêtes JamZY openid profile inference monetization_gateway. Cela ne demande pas payments et ne vend pas un produit via le paiement. Activer une capacité dans la Console ne la confère pas à un jeton d'accès existant : le client doit autoriser les portées et les conditions.
Les capacités, les portées configurées et la demande d'autorisation concordent. Évitez de demander un accès optionnel que votre application n'utilise jamais ou ne peut pas vérifier.
Vous créerez un client Web pour l'expérience basée sur le navigateur JamZY, avec la bonne méthode d'authentification.
Où vous travaillerez Paramètres OAuth → Web
Différentes plateformes ont des identifiants et des règles de rappel différents. Ce ne sont pas des produits distincts : les abonnements et la gestion des clients sont agrégés pour l'application. Les testeurs d'application sont partagés entre les plateformes, avec un maximum de cinq places, y compris les invitations en attente ; le propriétaire ne consomme pas une place de testeur.
Une seule plateforme Web existe. Les plateformes natives que vous n'avez pas configurées ne bloquent pas votre lancement.
Vous renverrez les clients vers votre application après l'autorisation, en utilisant un callback exact que vous possédez.
Où vous travaillerez Web → Configuration
Dans Web → Configuration, enregistrez le callback HTTPS exact que votre application gère. Ce guide utilise https://jamzy.example/oauth/callback comme exemple. Remplacez jamzy.example par le domaine HTTPS où vous déployez votre copie de JamZY, et utilisez ce même callback dans la configuration de votre application.
Fournissez le nom de l'écran de consentement, les conditions, les informations de confidentialité et de suppression. Activez uniquement les scopes dont vous avez besoin, puis enregistrez. Le schéma, l'hôte, le chemin et les détails de requête applicables doivent correspondre à la demande d'autorisation et à l'échange de code. N'utilisez pas de caractère générique ou de fragment d'URL.
| Plateforme | Rappel à implémenter |
|---|---|
| Web | Adresse HTTPS exacte sur votre application. |
| Android | Un schéma d'application en domaine inversé correspondant à l'ID de l'application, ou un lien d'application HTTPS vérifié avec le package et l'empreinte de signature SHA-256. |
| iOS | Un schéma d'application correspondant, ou un lien universel HTTPS vérifié avec l'ID du bundle et le préfixe de l'ID d'application Apple. |
| Windows / macOS / Linux | Un rappel HTTPS exact autorisé, un schéma d'application en domaine inversé correspondant, ou une redirection en boucle locale prise en charge sur 127.0.0.1 / [::1]. Le port de boucle locale peut varier. |
Les applications installées s'autorisent dans le navigateur système et reviennent via le rappel enregistré. Pour les liens d'application HTTPS revendiqués, publiez le fichier d'association requis et exécutez la vérification d'association dans la Console. Un rappel qui semble plausible dans un formulaire ne prouve pas que votre application installée le reçoit.
L'ouverture du rappel via le flux d'autorisation revient à votre application. Un code aléatoire ou un état non correspondant est rejeté.
Vous aurez l'interface de rendez-vous et sa connexion ShareAI fonctionnant avec vos propres identifiants d'application.
Où vous travaillerez Votre application → Configuration de l'environnement
JamZY est une application de rendez-vous avec un assistant de préparation IA optionnel. Son planificateur est une démonstration uniquement sur navigateur : il n'y a pas de fournisseur de calendrier, de livraison d'e-mails ou de paiement de rendez-vous. L'intégration d'autorisation et d'API IA ShareAI utilise la configuration réelle en amont.
Téléchargez le Référence source JamZY. Il contient le serveur Node, l'interface utilisateur du navigateur, les tests et un README de configuration ; pas de certificats, secrets, dépendances ou sessions. Examinez les fichiers avant de les exécuter. Placez le processus Node derrière un proxy inverse HTTPS qui préserve l'origine publique.
# .env — replace both identifiers with YOUR registered application.
JAMZY_PUBLIC_ORIGIN=https://jamzy.example
SHAREAI_CLIENT_ID=YOUR_WEB_CLIENT_ID
SHAREAI_APP_ID=YOUR_APPLICATION_UUID
SHAREAI_AUTH_ORIGIN=https://auth.shareai.now
SHAREAI_API_BASE_URL=https://api.shareai.now/api/v1
SHAREAI_SCOPES="openid profile inference monetization_gateway"
PORT=3443
BIND_HOST=127.0.0.1# Node 22+, behind your HTTPS reverse proxy
node --env-file=.env server.mjs
# Mocked upstream tests; these do not spend credits
node --test test/server.test.mjsCréez votre application sur console.partagerai.maintenant. Utilisez son ID client de production avec https://auth.shareai.now et https://api.shareai.now/api/v1. L' jamzy.example adresse est un espace réservé pour votre application, pas une démonstration hébergée. Servez votre propre application via HTTPS pour que son cookie de session sécurisé fonctionne.
JamZY propose également une connexion par clé API à titre de comparaison. Ce guide pratique utilise le bouton portefeuille/OAuth. Une clé API n'établit pas l'accord OAuth du client JamZY et ne remplace pas le flux d'autorisation du client.
L'application se charge via HTTPS. Son origine publique, son rappel enregistré et son ID client correspondent à votre enregistrement. Aucun jeton ou secret n'apparaît dans le code source de la page ou dans le localStorage.
Vous permettrez à un client de choisir son compte ShareAI et d'approuver l'accès dont votre application a besoin.
Où vous travaillerez JamZY → Payer avec votre portefeuille ShareAI
Depuis JamZY, sélectionnez Payer avec votre portefeuille ShareAI. L'application ouvre la page d'autorisation ShareAI. Le client se connecte, sélectionne un compte personnel ou organisationnel, vérifie l'application et l'accès demandé, et accepte les conditions d'abonnement applicables.
const verifier = randomBytes(32).toString('base64url');
const state = randomBytes(32).toString('base64url');
const challenge = createHash('sha256').update(verifier).digest('base64url');
const authorize = new URL('https://auth.shareai.now/oauth/authorize');
authorize.search = new URLSearchParams({
client_id: clientId, response_type: 'code', redirect_uri: callback,
scope: 'openid profile inference monetization_gateway', state,
code_challenge: challenge, code_challenge_method: 'S256',
}).toString();
// Save state + verifier in the server session BEFORE redirecting.
// The downloadable server implements state expiry and one-time consumption.Identifiez l'enregistrement client local par l'identité authentifiée, le contexte de client émetteur sub et son contexte émetteur/client. Les autorisations personnelles et organisationnelles peuvent sélectionner différents comptes payeurs. Un ID client n'est pas un ID utilisateur global, une adresse e-mail ou un ID de base de données interne d'organisation. Ne fusionnez pas les identités entre les plateformes en faisant correspondre les noms affichés.
Les annulations, les états non correspondants, les codes rejoués et les autorisations expirées échouent en toute sécurité. Le flux normal renvoie un compte authentifié sans exposer ses jetons.
Vous maintiendrez les requêtes autorisées fonctionnelles à mesure que les jetons expirent, tout en offrant au client un moyen fiable de se déconnecter.
Où vous travaillerez Votre application → Gestion des sessions et des jetons
| Identifiant | Objectif | Comment le gérer |
|---|---|---|
| Code d'autorisation | Transmission unique depuis la page d'autorisation. | Échangez-le une fois, en utilisant le vérificateur correspondant et le callback. Ce n'est pas un jeton API. |
| Jeton d'accès | Autorise les appels API dans le cadre de la subvention et des portées acceptées. | Envoyez-le comme Authorization: Bearer …. Respectez l'expiration et les erreurs d'autorisation des points de terminaison. |
| Jeton de rafraîchissement | Permet d'obtenir des jetons d'accès de remplacement sans une nouvelle connexion tant que la subvention reste valide. | Stockez-le en toute sécurité. Sérialisez les opérations de rafraîchissement et remplacez de manière atomique les identifiants tournants. |
| Jeton ID | Une assertion d'identité OpenID Connect pour le client. | Si vous l'utilisez, validez la signature, l'émetteur, l'audience, l'expiration et le nonce si applicable. Ne l'utilisez pas comme un jeton Bearer inféré. |
| Secret client | Authentifie un client serveur confidentiel autorisé. | Stockez-le sur le serveur. Il est différent de tous les jetons et n'est jamais inclus dans un client public. |
# Public client refresh; run on a trusted terminal with scoped test credentials.
curl --fail-with-body 'https://auth.shareai.now/oauth/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=refresh_token' \
--data-urlencode "client_id=$SHAREAI_CLIENT_ID" \
--data-urlencode "refresh_token=$SHAREAI_REFRESH_TOKEN"Utilisez le expires_in retourné au lieu d'inventer une durée de vie. Si le rafraîchissement retourne un jeton de rafraîchissement de remplacement, conservez-le avec le nouveau jeton d'accès comme une mise à jour unique. Autorisez un seul rafraîchissement en cours par session afin que les requêtes simultanées ne réutilisent pas un jeton tourné. Une subvention de rafraîchissement invalide ou révoquée nécessite une reconnexion ; ne bouclez pas indéfiniment.
Le rafraîchissement ne peut pas ajouter une portée ou accepter silencieusement un nouveau contrat Monetization Gateway. Envoyez à nouveau le client via l'autorisation pour obtenir de nouvelles permissions ou conditions. JamZY stocke les informations d'identification uniquement en mémoire serveur pour une session de démonstration d'une heure maximum, authentifie les informations utilisateur au lieu de se fier à un jeton d'identité non vérifié, et utilise un cookie sécurisé, HttpOnly, SameSite. Un service de production nécessite sa propre conception de session durable et protégée.
Lors de la déconnexion, révoquez les informations d'identification de rafraîchissement/d'accès si applicable et effacez la session de l'application. Effacer uniquement un cookie de navigateur ne révoque pas une subvention ShareAI ou n'annule pas un abonnement payant. Évitez de consigner des codes, des jetons, des secrets ou du contenu personnel de l'invite.
L'expiration déclenche un rafraîchissement contrôlé ; de nouveaux jetons remplacent les anciens. La déconnexion efface la session de l'application et signale tout échec de révocation.
Vous transformerez un objectif de rendez-vous en un ordre du jour et des questions utiles, avec une demande explicite d'IA financée par le client.
Où vous travaillerez Modèles disponibles → JamZY → Venez préparé
Ouvrez Modèles disponibles dans l'application. Sélectionnez les modèles et les fournisseurs que votre produit proposera et enregistrez la configuration. Si le catalogue ne peut pas être chargé, résolvez l'erreur de disponibilité en amont avant de continuer ; changer de manière répétée les clients OAuth ne le réparera pas.
JamZY charge son catalogue uniquement après connexion. Choisissez un modèle de texte autorisé, saisissez un objectif de rendez-vous court et sélectionnez Générer une préparation de manière délibérée. Le compte sélectionné doit disposer de crédits éligibles et de toutes les conditions de facturation d'IA requises acceptées. Choisir une date, examiner un rendez-vous et l'enregistrer n'envoie pas de demande d'inférence.
curl --fail-with-body 'https://api.shareai.now/api/v1/chat/completions' \
-H "Authorization: Bearer $SHAREAI_ACCESS_TOKEN" \
-H 'Content-Type: application/json' \
--data '{"model":"YOUR_ENABLED_MODEL_SLUG","messages":[{"role":"user","content":"Create a short agenda and three questions for a 15-minute appointment about planning a booking app."}],"stream":false,"max_tokens":192}'Un produit de planification réel nécessite un stockage de réservation côté serveur, des vérifications de disponibilité, une gestion des fuseaux horaires, une politique d'annulation et une intégration de calendrier ou de notification. Ceux-ci sont distincts de l'autorisation ShareAI. Gardez la sortie de l'IA comme une proposition ; validez toute action de réservation future via les règles de votre propre application.
Utilisez un slug de modèle renvoyé par le catalogue autorisé. Gérez le contrat de réponse réel : JamZY prend en charge le natif de ShareAI. message.content enveloppe et style OpenAI. choices[0].message.contentUn HTTP 200 avec une réponse d'erreur incomplète ou imbriquée n'est pas une réponse réussie.
En cas de réponse de limite de dépenses ou de crédit insuffisant, affichez une explication utile et le lien de facturation client fourni. Préservez le compte sélectionné. Ne contournez pas sa limite, ne changez pas de payeur silencieusement et ne réessayez pas une opération facturée en boucle.
Générer une préparation renvoie un agenda utilisable et des questions. La demande est attribuée au client et à l'application autorisés, avec le modèle sélectionné et les conditions acceptées. Le brouillon AI ne peut ni réserver ni modifier un rendez-vous.
Vous expliquerez vos frais AI supplémentaires dans une offre d'abonnement et publierez les conditions que les clients peuvent accepter.
Où vous travaillerez Application → Abonnements
Demandez l'accès à Monetization Gateway via les Cas d'utilisation de l'application si cela n'est pas déjà approuvé par la politique administrative applicable. Complétez le questionnaire et suivez son statut. L'approbation permet la configuration ; la permission du client et le consentement de facturation restent distincts.
Exemple uniquement : une majoration 20% Builder sur €1.00 du coût réseau éligible ajoute €0.20. Au tarif Standard, les frais ShareAI de 5% s'appliquent uniquement à cette majoration €0.20, avant tout Ingestion d'Événements facturable. Utilisez l'estimateur en direct et le contrat accepté pour le calcul réel. Une offre d'abonnement dans ce flux est un accord de facturation IA ; la connexion de compte seule ne débite pas un prix récurrent fixe.
surcharge pour cette offre.L’écran de consentement ShareAI est l’autorité pour les termes acceptés. Le client public de JamZY ne peut pas déduire le plan de facturation accepté à partir des informations utilisateur, donc son panneau de connexion ne revendique pas d’abonnement actif ni n’invente un prix pour le rendez-vous.
L’offre explique les frais ; le contrat peut être accepté par le client. Vous comprenez quels clients restent sur des termes plus anciens et pourquoi.
Vous collecterez le véritable point de terminaison et les vérifications de portée nécessaires pour soumettre votre application à l’examen.
Où vous travaillerez Paramètres OAuth → Testeurs et Vérification
Ouvrez les paramètres OAuth → Testeurs et invitez jusqu’à cinq testeurs à l’échelle de l’application. Les invitations en attente occupent une place mais ne donnent pas accès ; le destinataire doit accepter. L’accès propriétaire et l’accès des testeurs invités sont différents de l’accès public en production.
Pour chaque plateforme que vous souhaitez publier, ouvrez Vérification. Effectuez des appels réussis réels pour les points de terminaison requis et chaque portée configurée. Vérifiez les clés de découverte et de signature ; testez l’autorisation/rappel, l’échange de code, le rafraîchissement, les informations utilisateur authentifiées et la révocation. Les clients confidentiels doivent également tester l’introspection applicable. Les liens HTTPS revendiqués natifs nécessitent une vérification d’association.
Un champ de portée profil/email nécessite ses revendications retournées réelles ; utilisez un compte de test personnel lorsque l'email est requis. Les portées inference et monetization_gateway nécessitent une demande d'IA autorisée et complétée. Les paiements nécessitent un appel API de paiement avec portée réussi. Une réponse HTTP générique réussie, une capture d'écran du navigateur ou une liste de contrôle manuelle ne remplacent pas les vérifications enregistrées dans la Console.
Vous avez trois choix pour une plateforme inachevée : la terminer et la vérifier, l’exclure de la publication pour qu’elle reste réservée au propriétaire/testeur, ou la supprimer. N’incluez pas une plateforme avec des rappels ou des portées que vous n’avez pas exercés. Les modifications de configuration peuvent invalider les vérifications, donc actualisez le statut enregistré après vos modifications finales.
Chaque plateforme incluse affiche la configuration requise, les points de terminaison et les vérifications de portée comme complètes. La liste de contrôle personnelle du guide est uniquement une aide à la lecture.
Vous saurez ce qui est prêt pour l’examen, comment fonctionne la publication et où suivre l’accès des clients par la suite.
Où vous travaillerez Application → Tableau de bord
Essayez à nouveau tout le flux avec un client éligible après le lancement : connectez, inspectez le compte et le consentement, générez un brouillon court de préparation de rendez-vous, actualisez en toute sécurité, gérez un échec de facturation, puis déconnectez. Vérifiez l'expérience utilisateur en direct au lieu de supposer qu'une sauvegarde réussie prouve que cela fonctionne.
Incohérence de rappel : comparez exactement l'URL enregistrée et les deux valeurs de requête. Testeur non autorisé : confirmer l'acceptation de l'invitation et le compte sélectionné. Portée ou contrat manquant : demander uniquement l'accès activé et se reconnecter pour l'accepter. Aucun modèle : inspecter les Modèles Disponibles et les restrictions du fournisseur. Échec de l'actualisation : effacer la session locale échouée et se reconnecter. Révision bloquée : inspecter les vérifications de la plateforme plutôt que de créer un autre client OAuth.
L'application fonctionne pour le client prévu, les vérifications enregistrées soutiennent son état de publication, et le client peut contrôler ou révoquer l'autorisation.
Sélectionnez le compte personnel ou organisationnel qui possédera l'inscription au programme avant de postuler. Les organisations peuvent soumettre une candidature avant vérification, mais l'approbation par le personnel seule n'active pas l'accès. Complétez la vérification de l'email de l'organisation et de l'entreprise à partir de la liste de contrôle d'intégration dans la Console. Une organisation approuvée reste En attente de vérification jusqu'à ce que les deux vérifications soient terminées. Builder, Provider et Creator suivent cette règle.
Voir la tarification Monetization Gateway · Explorer ShareAI for Startups · Scopes et permissions
Vos Conditions générales, Politique de confidentialité et instructions de suppression publiques doivent correspondre à l'application et rester accessibles sans connexion. L'acceptation du programme ShareAI, l'approbation Monetization Gateway, l'autorisation OAuth du client et le contrat de facturation accepté sont des décisions distinctes. Un rafraîchissement ne peut pas ajouter de permissions ou accepter de nouveaux termes commerciaux.
Le champ d'application hérité surcharge reste accepté pour les intégrations existantes. Les nouveaux exemples utilisent monetization_gateway. Conservez les champs existants tels que surcharge_bps et surcharge_percentage inchangés.
Voir la tarification Monetization Gateway · Explorer ShareAI for Startups · Scopes et permissions
Les frais standards 5% de la majoration Builder. Pour €2.00 du coût du réseau IA et une majoration de 10%, le client paie €2.20. ShareAI reçoit €0.01 de la majoration €0.20 ; le Builder a €0.19 avant l'Event Ingestion.
Les premières 1,000 requêtes de Production réglées Monetization Gateway sont gratuites chaque mois calendaire (UTC), partagées sur le compte Builder. Les requêtes supplémentaires coûtent €0.04 par 1,000 avant les remises éligibles. Une requête réglée crée un événement.
Pay with ShareAI seul, accès inference-uniquement, les clés API de compte ordinaire et le trafic de mise en scène ou de test n'entraînent pas d'Ingestion d'Événements Monetization Gateway.
ShareAI for Startups offre une allocation mensuelle partagée pour les frais réels ShareAI sur une application approuvée. Les niveaux actuels Launch, Growth et Momentum listent €1,000, €5,000 et €10,000 par mois. Le même budget couvre les frais en pourcentage de ShareAI sur la majoration Builder et l'ingestion d'événements facturables ensemble. Ce n'est pas une allocation de majoration brute, un quota d'événements gratuits séparé ou une IA gratuite inference. Les premiers 1,000 événements gratuits du compte ne le consomment pas.
Les frais restants d'ingestion d'événements sont payés à partir des nouveaux revenus de la demande Builder, puis des revenus disponibles Builder d'IA et des crédits IA non restreints. Les frais IA des clients et le produit payments restent séparés.
ShareAI peut approuver des frais spécifiques à l'application ou un soutien aux frais pour une période fixe ou jusqu'à modification. Consultez les tarifs actuels de l'application et les programmes spéciaux dans la Console pour ses conditions approuvées, sa validité et son allocation consommée. Un changement de niveau ou une modification des tarifs ne réinitialise pas l'utilisation mensuelle de l'application.
Launch garde Connexion avec ShareAI facultatif. Growth et Momentum l'exigent ; Momentum exige également l'insigne officiel ShareAI for Startups dans le pied de page de l'application. ShareAI vérifie l'insigne chaque semaine. Les tentatives confirmées de contourner les exigences peuvent entraîner une rétrogradation, une suppression du programme Startup ou un retrait du Marketplace selon les conditions du programme acceptées.
Les tarifs entreprise sont configurés par l'équipe ShareAI pour le compte Builder après accord sur une offre personnalisée. Le pourcentage assigné et le tarif par événement s'appliquent aux requêtes futures.
Voir la tarification Monetization Gateway · Explorer ShareAI for Startups · Scopes et permissions