Guide de configuration SosoAPI

Choisissez votre point de départ

SosoAPI donne à l’agent que vous utilisez déjà une connexion à vos comptes sociaux. Votre agent aide à rédiger et vérifier le contenu ; SosoAPI gère les opérations de compte prises en charge, la planification et les résultats de publication. Vous pouvez consulter les mêmes publications dans l’app ou utiliser l’API depuis votre propre code.

Ce guide commence avec une personne et un compte social. Vous connecterez un client MCP local ou hébergé, choisirez les accès, vérifierez un compte social, préparerez et approuverez une publication, puis lirez son résultat réel. Le parcours avancé couvre la CLI et l’API HTTP. La configuration elle-même ne nécessite pas de publication de test.

• Laisser Claude Code ou Codex gérer la configuration : étape 1
• Configurer vous-même un client MCP : étape 3
• Utiliser un terminal ou un backend : étape 9
• Réparer une connexion : étape 10

Avant de commencer

Il vous faut un client IA compatible MCP, un compte SosoAPI et un compte social que vous êtes autorisé à gérer. Vous pouvez créer le compte SosoAPI à l’ouverture de la connexion. Prévoyez un véritable contenu à préparer.

MCP local nécessite Node.js 20 ou ultérieur avec npm/npx et le client IA choisi. MCP hébergé nécessite un client prenant en charge MCP distant, OAuth et l’enregistrement automatique des clients, sans installation locale de Node.js. Les fonctions du client peuvent dépendre de son offre et de ses paramètres administrateur.

SosoAPI connecte Instagram, Threads, Facebook Pages, YouTube et X. Choisissez un compte dont le type, les permissions et le format de publication correspondent à votre tâche. Un compte Threads éligible est un bon premier exemple pour du texte seul. Instagram et YouTube nécessitent des médias adaptés à leurs formats de publication pris en charge. La présence d’une plateforme dans le menu de connexion ne signifie pas que toutes les actions sont disponibles pour chaque compte.

Vérifiez les capacités propres au compte pendant la configuration. Consultez votre offre et votre quota actuels dans l’app avant de planifier un lot ; X dispose d’un crédit distinct au niveau de l’Organization. Un exemple pour une plateforme ne prouve pas sa prise en charge sur une autre.

• Plateformes prises en charge
• Capacités de publication et exigences des comptes

1. Donner la demande de configuration à votre agent

Collez ceci dans votre conversation existante avec Claude Code ou Codex.

L’agent doit d’abord rechercher une connexion SosoAPI fonctionnelle et la réutiliser. Sinon, il suit la procédure et vous indique quand une connexion navigateur ou un redémarrage du client est nécessaire. Résultat attendu : les outils SosoAPI sont utilisables dans cette conversation. Un message d’installation seul ne le prouve pas. Poursuivez avec la connexion et la vérification du compte, ou utilisez l’étape 3 pour la configuration manuelle.

Configurez SosoAPI à partir de https://sosoapi.ai/setup.md. Conservez mon contenu et ma tâche actuels. Je me connecterai et approuverai l’accès lorsque cela sera demandé. Ne publiez rien pendant la configuration.

2. Se connecter et choisir les accès de l’agent

Utilisez le compte souhaité : continuez avec Google, ou inscrivez-vous par e-mail et terminez la vérification. Terminez toute configuration de compte ou de Workspace affichée. Si vous appartenez à plusieurs Workspaces, choisissez la marque ou le projet souhaité. Vérifiez les Workspaces et actions demandés avant approbation, puis revenez à la même conversation.

Conservez le lien de connexion fourni par l’agent afin que le navigateur puisse revenir à l’autorisation en attente. Vous pouvez commencer dans l’app, puis revenir à l’agent. Ne remplacez pas un lien d’approbation en attente par un autre lien de connexion.

Les rôles de Workspace et permissions des plateformes restent applicables : un viewer ne devient pas editor parce qu’un agent dispose du droit de publier. Cet accès reste valable dans le périmètre accordé ; SosoAPI n’exige pas une nouvelle approbation navigateur à chaque publication. Indiquez à l’agent quand suspendre le travail pour vérifier le contenu. La configuration OAuth normale ne demande pas de coller un mot de passe social ou une clé API dans l’agent.

Résultat attendu : la connexion se termine avec l’identité souhaitée et l’agent peut récupérer les Workspaces autorisés. Consultez le dépannage si le mauvais profil de navigateur s’ouvre.

• Commencer dans l’app SosoAPI

3. Connecter votre agent manuellement si nécessaire

Choisissez une méthode de connexion. Ignorez cette section si l’agent a déjà configuré une connexion fonctionnelle. Pour MCP local, vérifiez d’abord Node.js et npx. Node.js doit être en version 20 ou ultérieure.

node --version
npx --version

MCP local : Claude Code ou Codex

Exécutez uniquement la commande de votre client : la première est pour Claude Code et la seconde pour Codex. Le profil core couvre la publication courante. Les profils changent les outils affichés, sans accorder de permissions. Conservez une connexion fonctionnelle avec le profil full si vous en avez déjà une.

Reconnectez ou redémarrez si le client le demande, puis vérifiez que les outils SosoAPI sont disponibles dans la conversation actuelle. Le premier appel authentifié lance la connexion navigateur si nécessaire.

claude mcp add sosoapi -e SOSOAPI_TOOL_PROFILE=core -- npx -y sosoapi

codex mcp add sosoapi --env SOSOAPI_TOOL_PROFILE=core -- npx -y sosoapi

Autres clients MCP locaux

Pour les clients utilisant le JSON mcpServers, ajoutez cette entrée à la configuration existante en conservant les autres serveurs. Pour les autres formats, renseignez la même commande, les mêmes arguments et la même variable d’environnement via les réglages MCP du client.

{
  "mcpServers": {
    "sosoapi": {
      "command": "npx",
      "args": [
        "-y",
        "sosoapi"
      ],
      "env": {
        "SOSOAPI_TOOL_PROFILE": "core"
      }
    }
  }
}

• Référence d’installation et choix des paquets

MCP hébergé : clients navigateur ou distants compatibles

Dans les réglages de connecteur personnalisé ou MCP distant du client, ajoutez une connexion nommée SosoAPI avec l’URL serveur ci-dessous. Choisissez OAuth avec enregistrement automatique des clients si proposé. Connectez-vous à SosoAPI, choisissez les Workspaces et actions autorisés, revenez à la conversation et activez la connexion si nécessaire. Demandez à l’agent de vérifier les comptes autorisés.

Utilisez https://sosoapi.ai pour une nouvelle connexion hébergée. L’ancien endpoint https://gqeshlawtcexsapabaui.supabase.co/functions/v1/remote-mcp reste pris en charge. Conservez une connexion locale ou hébergée fonctionnelle ; inutile de la remplacer uniquement pour changer son URL.

Aucune clé API, aucun ID client ni secret client à coller. Les apps MCP personnalisées de ChatGPT dépendent de l’offre, du mode développeur et des paramètres administrateur du client. Ces instructions décrivent une connexion personnalisée, pas un référencement dans l’annuaire d’apps. MCP hébergé ne lit pas les fichiers locaux ; utilisez une importation d’URL publique ou MCP local pour les envois locaux.

https://sosoapi.ai

• Enregistrement d’un client OAuth personnalisé et procédure de jeton

Vérification facultative de connexion dans le terminal

Pour une connexion locale, exécutez d’abord auth status. Lancez auth login uniquement si le statut indique que vous n’êtes pas connecté. Terminez le parcours navigateur et revérifiez le statut. Les jetons ne sont pas affichés. Cela vérifie l’authentification locale de la CLI, pas la connexion d’un connecteur hébergé distinct.

npx -y sosoapi auth status

npx -y sosoapi auth login

4. Connecter votre compte social

Ouvrez Connecter des comptes ou utilisez la commande locale ci-dessous. Remplacez threads par instagram, facebook, youtube ou x selon le cas. Cela ouvre le parcours de connexion ; aucun contenu n’est publié.

Vérifiez l’Organization et le Workspace affichés. Choisissez la plateforme, connectez-vous via sa page d’autorisation et sélectionnez précisément le compte, la Page ou la chaîne. Au retour, terminez le consentement et toute confirmation de sélection de compte. Demandez ensuite à l’agent d’actualiser les comptes connectés du Workspace souhaité.

Réutilisez une connexion existante en bon état. Si elle appartient à une autre Organization ou à un autre Workspace, réglez ce choix dans l’app ; la configuration courante ne doit ni la déconnecter ni la déplacer. Résultat attendu : le bon compte apparaît dans le Workspace souhaité avec son état et ses capacités à jour. Un callback réussi ne prouve pas à lui seul l’autorisation de publier.

npx -y sosoapi connect threads

• Connecter des comptes

5. Vérifier l’accès sans publier

Collez ce qui suit dans la conversation avec l’agent connecté.

L’agent peut utiliser sosoapi_get_workspace_context et sosoapi_list_connected_accounts, réutiliser le contexte connu et transmettre explicitement le workspace_id choisi. L’initialisation du compte peut créer votre premier Workspace ; cette vérification de configuration ne crée aucune publication sociale.

Avant de continuer, confirmez le Workspace et la destination, votre rôle et les accès de l’agent, ainsi que la prise en charge du format prévu. Consultez le dépannage si une vérification échoue. Réinstaller un paquet ne corrige pas une permission de plateforme manquante.

Vérifiez ma configuration SosoAPI sans rien publier ni planifier.
Affichez les Workspaces que je peux utiliser et les comptes sociaux dans celui que je choisis.
Pour le compte choisi, affichez la plateforme, le libellé du compte, l’état de connexion et les capacités de publication pour le format proposé.
Si plusieurs Workspaces ou comptes peuvent convenir, demandez-moi lequel utiliser.
Gardez les ID internes pour les appels d’outils ; ne me demandez pas de les chercher ou de les inventer.

6. Préparer et approuver votre première publication

Commencez par une véritable publication et une destination. Remplacez les champs entre crochets dans cette demande de brouillon. L’agent rédige ; SosoAPI fournit la connexion et les opérations de publication. Vérifiez vous-même les affirmations, l’orthographe, les liens et les médias.

Utilisez une date, une heure locale et un fuseau IANA explicites pour une publication future. Si le changement d’heure rend l’heure locale ambiguë, choisissez l’occurrence voulue avant soumission. Résultat attendu à ce stade : un brouillon précis à vérifier, sans requête de publication soumise.

Aidez-moi à préparer une annonce de produit avec SosoAPI.

Produit : [nom public du produit]
Faits vérifiés : [ce qui est disponible aujourd’hui]
Public : [à qui cela est utile]
Destination : [libellé du compte et plateforme]
Langue : [langue]
Date et heure locales souhaitées : [YYYY-MM-DD HH:mm]
Fuseau horaire : [fuseau IANA, par exemple Asia/Hong_Kong]
Médias : [aucun, un fichier local ou une URL de média publique]

Utilisez uniquement les faits que j’ai fournis. Vérifiez les exigences de format de la destination.
Présentez le brouillon exact, les médias, la destination, la date, l’heure et le fuseau horaire pour vérification.
Ne planifiez et ne publiez pas encore.

Approuver la publication exacte avant de la planifier

Lorsque tous les détails sont corrects, donnez une instruction précise avec la demande ci-dessous. Cela crée une véritable planification pouvant publier publiquement. Utilisez un contenu et un compte sur lequel vous souhaitez publier. La publication immédiate nécessite aussi une instruction explicite après vérification des mêmes détails.

Résultat attendu : un ID de Scheduled Post, la destination souhaitée, l’horaire accepté et le statut actuel. Une planification acceptée ne signifie pas que le fournisseur l’a publiée.

Planifiez la publication exacte approuvée ci-dessous sur le compte nommé, à la date, à l’heure et dans le fuseau indiqués.

[Collez le contenu final, les médias, la destination, la date, l’heure et le fuseau horaire.]

Vérifiez d’abord s’il existe une planification correspondante. Soumettez cette publication une seule fois et relisez le résultat enregistré. Renvoyez son ID, sa destination, l’horaire accepté et son statut actuel. Si le résultat est incertain, vérifiez la requête existante avant toute autre action.

7. Vérifier le résultat, replanifier ou annuler

Demandez à l’agent de lire le même Scheduled Post avec sosoapi_get_scheduled_post. Vous pouvez aussi ouvrir https://app.sosoapi.ai/scheduled-posts/<post-id> après connexion avec un compte autorisé. Vérifiez chaque destination séparément lorsqu’une requête vise plusieurs comptes ; certaines peuvent réussir et d’autres nécessiter une intervention.

Lisez le résultat actuel du Scheduled Post [ID renvoyé].
Affichez sa destination, l’horaire planifié, le statut actuel et le résultat de publication.
Si la publication est confirmée, incluez le lien en ligne s’il est disponible.
Ne réessayez pas, ne replanifiez pas et ne créez aucune autre publication.

Gérer une publication en attente et y revenir plus tard

Pour modifier une publication en attente, fournissez son ID et les nouveaux détails. L’agent doit lire sa version actuelle et les actions disponibles avant une modification ou annulation prise en charge. L’annulation dépend de l’étape de livraison et peut devenir indisponible dès son démarrage. Annuler une planification ne supprime pas une publication déjà publiée chez le fournisseur.

Après réception des détails enregistrés d’une planification future, vous pouvez quitter la conversation et revenir à la même publication plus tard. Une conversation d’agent fermée ne promet pas de se réveiller ou de vous avertir, sauf configuration distincte.

8. Ajouter des images ou une vidéo et réutiliser le parcours

Faites fonctionner le parcours pour une seule publication avant de préparer un lot plus important. Indiquez à l’agent si le média est un fichier local, une URL publique ou une ressource SosoAPI existante.

Fichiers locaux : MCP local peut utiliser sosoapi_upload_asset. Le fichier doit se trouver dans un dossier de téléversement autorisé ; l’outil précise les emplacements permis si le chemin dépasse ces limites. MCP hébergé ne peut pas lire les fichiers de votre ordinateur.

URL publiques : utilisez sosoapi_import_asset_url, puis sosoapi_get_asset_import_status avec include_asset=true. Attendez que la ressource soit prête. Pour une ressource existante, vérifiez qu’elle appartient au Workspace souhaité et qu’elle est prête pour le format choisi.

La requête normale de planification utilise ensemble l’ID de la ressource enregistrée et son URL canonique. Une URL de prévisualisation temporaire ou l’URL externe d’origine ne les remplace pas. Pour le parcours pris en charge avec une URL d’image, sosoapi_post_image_url combine importation et soumission. Il s’agit d’une opération de publication : approuvez d’abord le contenu complet. Conservez l’ID de la publication acceptée pendant le traitement ; ne lancez pas une autre importation pour la poursuivre.

X prend en charge une publication TEXT originale sans média, ou VIDEO avec exactement une ressource vidéo MP4 enregistrée et prête, d’au moins 0.5 seconde et dans la limite d’envoi de 500 MiB. La vidéo exige can_publish_video vérifié pour le compte précis ; l’accès au texte seul ne suffit pas. Une ancienne connexion peut nécessiter votre accord pour se reconnecter avec l’autorisation d’envoi vidéo. Texte, hashtags et lien doivent respecter la limite pondérée de X. Photos, réponses, citations, republications et publications en fil ne sont pas prises en charge. L’acceptation d’un envoi ou d’un traitement vidéo n’est pas un résultat publié.

Avant une soumission X, lisez sosoapi_get_x_usage pour le workspace_id souhaité et le texte final. Son quota et son coût sont distincts du quota général de l’offre. Ne contournez pas une limite de crédits en répétant les soumissions ; rapprochez une publication incertaine avant un nouvel envoi.

Préparer un lot vérifié et lire les performances honnêtement

Après votre première publication réussie, essayez la demande de lancement de produit ci-dessous. Une fois le tableau exact approuvé, vérifiez le lot par rapport aux limites de l’offre. Signalez séparément les destinations acceptées et refusées et conservez l’identité de chaque publication acceptée.

Les accès à la publication et aux analyses peuvent différer. Si vous demandez ensuite un bilan de performance, les métriques indisponibles doivent être signalées comme telles. N’inventez pas de zéros et ne supposez pas que toutes les métriques sont lisibles parce qu’une publication a été publiée.

Avec la même configuration vérifiée, préparez sept brouillons d’annonce de produit, un par jour, à partir des faits publics que je fournis. Présentez un tableau de vérification avec, pour chaque ligne, brouillon, destination, médias, date locale, heure et fuseau horaire. Gardez les sept en brouillon jusqu’à mon approbation du tableau exact.

9. Parcours CLI et API

Utilisez ce parcours facultatif pour des fichiers de requêtes explicites ou une intégration backend. Les utilisateurs d’agents peuvent l’ignorer. Les exemples utilisent les mêmes permissions de compte, Workspace et publication que MCP.

Consultez d’abord l’aide et le contrat intégré du paquet installé ; leur consultation ne nécessite pas de connexion. Ils montrent les opérations et schémas fournis avec ce paquet. Utilisez ces noms de champs plutôt que le format de requête d’un autre fournisseur.

npx -y sosoapi --help
npx -y sosoapi api contract --summary
npx -y sosoapi api contract --route /studio-api/scheduled-posts/

CLI : première requête de contexte authentifiée

Terminez auth login. Avec un éditeur de texte, enregistrez workspaces.json contenant le JSON ci-dessous, puis exécutez la commande. Utilisez des fichiers pour les corps de requêtes au lieu d’insérer du contenu dans des commandes shell.

La CLI renvoie schema_version, http_status et body. Une réponse réussie inclut body.active_workspace_id et body.workspaces. Choisissez le Workspace souhaité dans cette réponse ; le Workspace actif ne décide pas implicitement de la destination d’une nouvelle tâche. Le premier appel d’un nouveau compte peut initialiser son premier Workspace.

Vérifiez http_status et body, pas seulement le code de sortie du shell. Une commande peut renvoyer une enveloppe d’erreur HTTP sans que l’opération API ait réussi.

{}

npx -y sosoapi api post /identity-api/workspace/list < workspaces.json

CLI : choisir le compte social connecté

Enregistrez accounts.json avec l’ID du Workspace renvoyé pour votre compte, puis exécutez la commande. Sélectionnez le compte souhaité dans body.accounts. Son ID de compte SosoAPI est le social_account_id utilisé pour la planification ; un nom d’utilisateur ou un ID de Page du fournisseur ne le remplace pas.

{
  "workspace_id": "<YOUR_WORKSPACE_ID>"
}

npx -y sosoapi api post /identity-api/user/social-accounts/list < accounts.json

CLI : planifier un texte Threads approuvé

Il s’agit d’un modèle de requête, pas d’une publication prête à exécuter. Enregistrez post.json avec un éditeur et remplacez chaque valeur entre crochets par vos valeurs autorisées. Choisissez un horodatage ISO futur avec un décalage UTC explicite, ou Z pour UTC. display_timezone est un fuseau IANA d’affichage ; il ne rend pas complet un horodatage local ambigu.

Générez un idempotency_key unique, par exemple un UUID, et conservez-le avec le corps exact de la requête. Réessayez une requête identique avec la même clé ; une réponse tardive ne justifie pas une nouvelle clé. Une publication modifiée est une autre requête : vérifiez le résultat d’origine avant de choisir une nouvelle identité.

Après confirmation du contenu, du compte, de l’horaire, des permissions et du quota actuel, exécutez la commande create. Elle planifie une véritable publication. Si elle est acceptée, conservez body.post.id et lisez body.post.status, body.post.scheduled_at et body.post.destination. body.deduped indique si une requête existante a été réutilisée. L’acceptation ne signifie pas une publication confirmée par le fournisseur.

{
  "workspace_id": "<YOUR_WORKSPACE_ID>",
  "social_account_id": "<YOUR_THREADS_ACCOUNT_ID>",
  "caption": "<YOUR_APPROVED_POST_TEXT>",
  "hashtags": [],
  "media": [],
  "provider_payload": {
    "platform": "threads",
    "publish_options": {
      "post_type": "TEXT"
    }
  },
  "scheduled_at": "<FUTURE_ISO_8601_TIME_WITH_OFFSET>",
  "display_timezone": "Asia/Hong_Kong",
  "idempotency_key": "<NEW_STABLE_REQUEST_KEY>"
}

npx -y sosoapi api post /studio-api/scheduled-posts/create < post.json

CLI : lire la publication enregistrée et son résultat

Enregistrez post-status.json avec l’ID renvoyé. Lisez body.post, body.delivery, body.actions et body.outcomes. Confirmez un résultat publié avant d’annoncer le succès. Si la réponse create est perdue, récupérez la requête d’origine avec son identité enregistrée ; ne créez pas une autre planification avec une nouvelle clé.

{
  "id": "<RETURNED_POST_ID>"
}

npx -y sosoapi api post /studio-api/scheduled-posts/get < post-status.json

CLI : annuler uniquement si le résultat actuel le permet

Si la dernière lecture autorise l’annulation et que vous souhaitez annuler, enregistrez cancel.json avec l’ID renvoyé et la valeur numérique actuelle de body.post.version. La valeur 1 de l’exemple est illustrative : remplacez-la par la version que vous venez de lire. Exécutez ensuite la commande et confirmez le résultat.

Si la version a changé ou si l’annulation est indisponible, relisez la même publication et utilisez ses actions réellement disponibles. Ne contournez pas un conflit de version et ne confondez pas annulation et suppression d’une publication déjà publiée.

{
  "id": "<RETURNED_POST_ID>",
  "expected_version": 1
}

npx -y sosoapi api post /studio-api/scheduled-posts/cancel < cancel.json

HTTP : appeler depuis votre propre backend

Pour une intégration côté serveur, créez une clé API dans Connection → API et stockez le secret dans la configuration sécurisée du serveur. L’écran actuel demande un nom ; il ne propose aucun sélecteur de Workspace ou de capacité. Une clé créée par un utilisateur dispose par défaut de operate, publish et engage sur les Workspaces accessibles à cet utilisateur. Vérifiez que ces autorisations conviennent à votre intégration. Le contrat API permet de limiter explicitement capabilities et workspace_ids pour une clé restreinte.

La configuration normale d’un agent utilise OAuth et n’exige pas cette étape de clé API. Dans l’exemple, SOSOAPI_ACCESS_TOKEN est votre variable d’exemple côté serveur contenant la clé ; ce n’est pas un réglage de la CLI SosoAPI. La variable facultative de jeton d’accès personnel de la CLI est VICKY_API_KEY.

Utilisez le fichier workspaces.json ci-dessus. HTTP direct renvoie le corps de l’endpoint sans l’enveloppe http_status/body de la CLI ; lisez le statut HTTP réel et le JSON. Gardez les identifiants côté backend, hors du code navigateur, des prompts, captures et fichiers de requêtes partagés.

Intégrer la connexion sociale dans un produit destiné à vos propres clients est une tâche d’intégration distincte. Ce parcours pour un seul compte ne prouve pas que ce parcours d’accueil client est prêt.

curl --fail-with-body --silent --show-error \
  -H "Authorization: Bearer ${SOSOAPI_ACCESS_TOKEN}" \
  -H 'Content-Type: application/json' \
  --data-binary @workspaces.json \
  'https://gqeshlawtcexsapabaui.supabase.co/functions/v1/identity-api/workspace/list'

• Gérer les clés API : Connection → API
• Référence API
• Création de clés API et autorisation explicite
• Authentification et autorisations
• Référence CLI

10. Dépannage

Basez-vous sur l’erreur réelle et la connexion diagnostiquée. Élargir les permissions ou répéter une soumission ne corrige pas tous les échecs.

Mettre à jour, révoquer l’accès ou demander de l’aide

La première commande ci-dessous consulte l’aide du dernier paquet sans démarrer le serveur MCP. Si le client fixe une version dans sa commande enregistrée, mettez cette commande à jour délibérément. Mettre à jour une installation globale distincte ne modifie pas la copie épinglée du client.

Pour révoquer un appareil local, utilisez Connection → Agent ou la commande auth logout ci-dessous. Pour un connecteur hébergé, révoquez l’autorisation correspondante dans Connection → Agent. Les clés API se gèrent séparément dans Connection → API. Révoquer l’accès de l’agent n’annule pas les planifications déjà acceptées ; gérez ces publications séparément.

Pour obtenir de l’aide, indiquez les versions du client et du paquet, l’étape en échec, l’erreur affichée et l’heure/fuseau. Partagez en privé les ID de requête ou de publication pertinents avec le support si nécessaire. N’envoyez pas d’identifiants, de liens d’autorisation ni de journaux bruts pouvant contenir des jetons.

npx -y sosoapi@latest --help

npx -y sosoapi auth logout

• Gérer les clients agents : Connection → Agent
• Gérer les clés API : Connection → API
• Référence de dépannage
• Contacter le support SosoAPI

Liste de vérification de configuration

Vous pouvez terminer la connexion sans soumettre de publication. Si vous publiez, utilisez la vérification séparée du résultat pour confirmer ce premier parcours de publication.

• Mon client peut utiliser les outils SosoAPI, ou ma CLI/API peut envoyer une requête autorisée.
• Je me suis connecté avec le compte souhaité et j’ai choisi le bon Workspace.
• Mon compte social apparaît avec les capacités nécessaires à la tâche.
• Je sais si mon agent peut préparer le travail ou aussi planifier et publier.
• Je peux préparer un brouillon et vérifier précisément la destination, le contenu et l’horaire.
• Si j’ai soumis une publication, j’ai conservé son ID et je sais distinguer acceptation et publication confirmée.
• Je sais examiner un échec, gérer une publication planifiée en attente et révoquer l’accès.