Intégration OAuth partenaire

Beta. Le mode OAuth est déployé progressivement. Contactez-nous pour faire enregistrer votre application.

Si vous prévoyez d’intégrer ofox à votre produit, vos utilisateurs peuvent cliquer sur un bouton OAuth, se connecter et donner leur autorisation sur ofox, puis revenir dans votre application. Les nouveaux utilisateurs inscrits de cette manière sont automatiquement attribués à votre canal partner, exactement comme s’ils s’étaient inscrits via votre lien de parrainage.

Comment l’intégrer

Vous pouvez faire la demande même si l’application est encore en développement : inutile d’attendre que le produit soit terminé. L’intégration OAuth est en Beta et les informations d’enregistrement sont validées par l’équipe.

Si vous n’avez pas encore rejoint le programme partenaires, faites d’abord une demande sur la page Partner ; les partenaires déjà inscrits ou activés n’ont pas besoin de refaire la demande.
Envoyez les informations d’enregistrement ci-dessous à hi@ofox.ai ou répondez à un e-mail de support existant.
Après vérification des informations de l’application, de l’adresse de redirection et des autorisations requises, nous enregistrons l’application OAuth, la rattachons à votre canal de parrainage et vous fournissons la configuration d’intégration.
Implémentez OAuth 2.1 dans votre produit et vérifiez l’autorisation, le retour dans l’application et les appels de modèles.

L’attribution au canal ne nécessite aucun paramètre de parrainage supplémentaire : nous la configurons lors de l’enregistrement. L’adresse de redirection, les autorisations et le flux d’autorisation OAuth doivent toujours être implémentés selon la configuration fournie.

Informations nécessaires pour enregistrer l’application

Information	À préciser
Nom et objectif de l’application	Un nom provisoire convient ; décrivez les fonctions principales, les utilisateurs visés et la façon dont vous utilisez les modèles ofox
Type d’application	Web, client de bureau, application mobile, extension de navigateur ou outil en ligne de commande ; présence ou non d’un backend
Adresse de redirection OAuth (Redirect URI)	Adresse complète de retour vers l’application après autorisation ; indiquez séparément test et production. Elle doit être confirmée avant l’enregistrement ; si elle n’est pas encore définie, décrivez d’abord la solution technique
Informations partner	E-mail utilisé pour la demande au programme partenaires et lien ou code de parrainage ; inutile de répéter ce qui figure déjà dans le même e-mail
Fonctions nécessaires	Appel de modèles, affichage du solde ou de l’utilisation, lecture des informations d’organisation, maintien de la connexion ; décrivez simplement le besoin, sans choisir vous-même toutes les autorisations
Lien du produit et logo (peuvent suivre)	Site, dépôt, page de démo ou captures d’écran si vous en avez ; si le produit n’est pas encore lancé, une courte présentation suffit et le logo peut être envoyé plus tard

L’adresse de redirection doit correspondre exactement à la valeur enregistrée ; les caractères génériques ne sont pas pris en charge. Protocole, domaine, port, chemin et / final doivent être identiques. HTTPS est recommandé en production web. Pour le bureau, le mobile ou le développement local, précisez le mode de redirection lors de l’enregistrement.

Il n’est pas nécessaire de fournir le code source complet ni un produit terminé pour demander une intégration. N’envoyez jamais de mot de passe, API Key, Client Secret ou Access Token dans l’e-mail de demande.

Copiez le modèle ci-dessous et indiquez « à confirmer » pour les points encore indéterminés :


Nom de l’application :
Objectif / utilisateurs visés :
Type d’application / backend :
Adresse de redirection (test) :
Adresse de redirection (production) :
E-mail de la demande Partner :
Lien ou code de parrainage Partner :
Fonctions nécessaires :
Lien / présentation du produit (le cas échéant) :
Logo (le cas échéant) :

À confirmer avant l’intégration

Type de client : une application dotée d’un backend capable de conserver des secrets en sécurité et une application exécutée directement dans le navigateur, sur ordinateur ou sur mobile n’utilisent pas la même configuration. Décrivez l’architecture réelle ; ne placez jamais le Client Secret dans le code frontend ni dans un installeur distribué aux utilisateurs.
Portée des autorisations : ne demandez que les autorisations réellement nécessaires. L’appel de modèles nécessite llm.invoke ; le reste est validé selon le besoin, et les autorisations accordées sont celles du résultat d’autorisation effectif.
Tests d’intégration : après l’enregistrement, intégrez selon la configuration fournie ; en cas de problème, indiquez les étapes, le message d’erreur expurgé et l’heure de l’incident, sans envoyer de jetons ni de clés.

Ce qui est attribué

Uniquement les nouvelles inscriptions. Lorsqu’un utilisateur sans compte ofox clique sur votre bouton OAuth, il est dirigé vers la page de connexion ofox, bascule vers l’inscription et la finalise — c’est à cet instant que la liaison à votre canal est créée. Ses rechargements et sa consommation relèvent ensuite du règlement normal des commissions partenaires.

Les utilisateurs disposant déjà d’un compte ofox conservent leur attribution. Autoriser votre application ne la modifie pas — même si l’utilisateur n’a jamais été attribué à aucun partenaire. Cela vaut aussi bien pour les utilisateurs déjà liés à un autre partenaire que pour ceux sans aucune liaison.

C’est délibéré : une liaison d’affiliation est permanente et exclusive pour la durée de vie du compte. Autoriser la réattribution permettrait à un partenaire de récupérer les utilisateurs apportés par un autre.

Scope au premier appel

L’access token reçu juste après l’inscription peut ne pas encore contenir llm.invoke.

llm.invoke n’est accordé qu’aux utilisateurs dont l’adresse e-mail est vérifiée. Que ce soit déjà le cas au moment de l’inscription dépend de la méthode utilisée :

Méthode d’inscription	E-mail vérifié à la fin	`llm.invoke` dans le premier token
Lien sans mot de passe	Oui — cliquer sur le lien constitue la vérification	Accordé
E-mail + mot de passe	Pas encore	Retiré jusqu’à vérification

Lorsqu’un scope est retiré, la requête de token réussit quand même — le champ scope de la réponse liste ce qui a réellement été accordé (RFC 6749 §3.3). Lisez ce champ plutôt que de supposer avoir obtenu tout ce que vous avez demandé. Appeler l’API LLM sans llm.invoke renvoie 403 insufficient_scope.

Une fois l’e-mail vérifié par l’utilisateur, demandez un nouveau token (ou rafraîchissez-le) et llm.invoke y figurera.

Commission

Les utilisateurs attribués sont réglés selon la commission partenaire standard par paliers (jusqu’à 9 %), calculée sur l’usage réel de l’API. Versements à partir de 50 $, règlement mensuel. Consultez la page Partenaires pour les conditions en vigueur.