Comment automatiser le provisionnement en tant que revendeur ?

Vous obtenez un jeton de revendeur (rk_…) dans l'espace Partners et appelez avec lui le même endpoint MCP (ou l'API REST). Le jeton est filtré par rôle : il expose 30 outils reseller_* couvrant tout le cycle de vie client — créer une offre, ajouter un client, commander une VM pour lui, lire le statut, suspendre, réactiver, renouveler, annuler. Commander un serveur pour un client devient un seul appel authentifié au lieu d'une session dans le tableau de bord.

Quelle est la différence entre l'API et MCP ici ?

Les mêmes capacités, deux portes. L'API REST est ce que vous scriptez depuis votre backend ou votre facturation. L'endpoint MCP expose ces mêmes outils reseller_* à un agent IA ou à un client compatible MCP, pour qu'un modèle les pilote directement. Vous pouvez utiliser l'un, l'autre ou les deux — un webhook de facturation qui provisionne via REST, et un agent qui fait le reste via MCP.

Un agent IA peut-il vraiment gérer la commande et la suspension ?

Oui — c'est à cela que sert la surface MCP. Comme les outils de revente sont exposés à MCP, un agent authentifié par votre jeton rk_ peut commander une VM quand un client paie, lire son statut, la suspendre en cas d'impayé et la réactiver au règlement, le tout sans humain cliquant dans un panneau. Vous fixez la politique ; l'agent l'exécute.

Comment mon accès revendeur est-il authentifié et cadré ?

Par un jeton de revendeur (rk_…) envoyé comme Authorization: Bearer rk_… . Il est filtré par rôle sur les seuls outils reseller_*, il opère donc vos clients et vos offres, pas la plateforme entière. Gardez le jeton secret comme tout identifiant ; c'est la clé de tout votre parc de clients.

Dois-je tout automatiser d'un coup ?

Non. Commencez par provisionner depuis le tableau de bord, puis déplacez les actions les plus fréquentes vers l'API à mesure que vous grandissez — d'ordinaire la commande-au-paiement et la suspension-à-l'impayé d'abord. L'intérêt est que l'effort opérationnel cesse de croître avec le nombre de clients dès que ces deux-là sont automatisés, et c'est ce qui rend un gros portefeuille de revente rentable.

Automatiser votre activité de revente de VPS via API et MCP

Une activité de revente gérée à la main atteint vite un plafond : chaque commande, chaque suspension, chaque renouvellement, c'est un humain qui clique dans un panneau, et votre temps croît avec le nombre de clients. Le moyen de franchir ce plafond est de faire tourner l'opération comme du code — et EQVPS expose le côté revente via une API REST et un endpoint MCP, pour que vous puissiez le scripter ou le confier à un agent IA.

Un jeton, 30 outils de revente

Vous obtenez un jeton de revendeur (rk_…) dans l'espace Partners et l'envoyez comme Authorization: Bearer rk_…. Ce jeton est filtré par rôle : il expose 30 outils reseller_* sur le même endpoint MCP, couvrant tout le cycle de vie client :

créer une offre et fixer son prix,
ajouter un client,
reseller_order_for_client — commander une VM sous votre marque,
lire son statut,
reseller_suspend_client / reseller_unsuspend_client — suspendre et rétablir,
renouveler et annuler.

Commander un serveur cesse d'être une session dans le tableau de bord et devient un seul appel authentifié.

API ou MCP — les mêmes capacités, deux portes

Ce ne sont pas des options concurrentes ; ce sont deux entrées vers les mêmes outils :

API REST — ce que vous scriptez depuis votre backend ou votre facturation. Un webhook de paiement se déclenche, votre code appelle l'endpoint de commande, la VM est provisionnée sous votre marque.
Endpoint MCP — les mêmes outils reseller_* exposés à un agent IA ou à un client compatible MCP, pour qu'un modèle les pilote directement.

La plupart des revendeurs utilisent les deux : un webhook de facturation qui provisionne via REST, et un agent qui gère les décisions plus délicates via MCP.

L'atout : un agent qui gère l'opération

C'est là que cela cesse de ressembler à tout autre programme de revente. Comme les outils de revente sont sur MCP, un agent IA authentifié par votre jeton rk_ peut gérer l'activité directement — commander une VM quand un client paie, lire le statut, suspendre à l'impayé, réactiver au règlement — sans humain dans la boucle. La même plateforme où un agent peut acheter et faire tourner son propre serveur permet à un agent de gérer un parc pour le compte de vos clients. Vous fixez la politique ; l'agent l'exécute. C'est l'activité d'hébergement gérée par IA comme motif concret.

Un flux minimal

// authentifiez chaque appel avec votre jeton de revendeur
// Authorization: Bearer rk_...

reseller_order_for_client({ client_id, product: "small", os_id: 1 })  // provisionner sous votre marque
// → service_id, ip, accès — livrez-le à votre client comme le vôtre
reseller_suspend_client({ service_id })       // à l'impayé
reseller_unsuspend_client({ service_id })      // au règlement

Quatre appels remplacent ce qui était autrefois une session dans le panneau par client, par événement.

Portée honnête

Le jeton est un identifiant. rk_… est la clé de tout votre parc de clients — stockez-le comme tel, et faites-le tourner s'il est exposé.
L'automatisation exécute votre politique, pas la sienne. Un agent qui commande et suspend ne vaut que les règles que vous lui donnez ; bornez les dépenses par un solde prépayé pour qu'un bug ou une mauvaise instruction ne dérape pas.
Le support et la facturation restent à vous. L'automatisation retire le clic, pas la relation client.

Où aller ensuite

La référence complète — authentification, outils reseller_*, gestion d'os_id et statuts — est dans la documentation reseller API / MCP. Nouveau côté activité ? Commencez par comment lancer une activité de revente de VPS. Le côté gros est le programme de revente en marque blanche.