Obtenez un jeton d’accès OAuth, trouvez une action dans le catalogue public et appelez-la sur POST /api/v1/actions/<id>.
Agents, preuves, gouvernance, commerce et divulgation sont dans Trustvice 360. Inscrivez-vous gratuitement et ouvrez toutes les suites depuis un seul tableau de bord.
Vous voulez qu’un appelant automatique, agent ou script, utilise une capacité de Trustvice. Chaque capacité est une action enregistrée avec un identifiant stable, une entrée typée et la même enveloppe de réponse : une seule forme de requête les couvre toutes.
Trustvice 360
tvc_… et son secret)curlLe code lit les secrets dans des variables d’environnement. Gardez-les dans votre shell ou votre coffre à secrets, jamais dans un fichier que vous committez. Les appels d’action envoient aussi X-Workspace-Id.
Échangez l’identifiant et le secret de votre client OAuth contre un jeton d’accès avec client_credentials. Le jeton vit une heure (expires_in: 3600) et porte le périmètre de permissions du client. Exportez-le sous TRUSTVICE_TOKEN.
Chaque action répond dans la même enveloppe : ok: true avec data, ou ok: false avec un code et un message dans error.
{ "ok": true, "data": { …action output… } }
{ "ok": false, "error": { "code": , : } }401 unauthenticated net, jamais une requête à moitié authentifiée.403 permission_denied en nommant la permission exacte requise.curl -sS -X POST https://api.trustvice.com/api/v1/oauth/token \
-H "Content-Type: application/json" \
-d "{\"grant_type\":\"client_credentials\",\"client_id\":\"tvc_…\",\"client_secret\":\"$TRUSTVICE_CLIENT_SECRET\"}"POST /api/v1/oauth/token
{ "grant_type": "client_credentials",
"client_id": "tvc_…", "client_secret": "…" }Le catalogue public des actions enregistrées est servi sur GET /api/v1/actions, sans identifiant. Les identifiants d’action sont hiérarchiques : <domain>.<noun>.<verb>. La référence de l’API liste le schéma d’entrée et les permissions de chaque action.
curl -sS https://api.trustvice.com/api/v1/actionsEnvoyez l’entrée de l’action en JSON à POST /api/v1/actions/<action-id>, avec le jeton d’accès et l’identifiant de votre workspace. Les clés API de workspace sont refusées ici à dessein : une clé API donne accès au workspace, pas une intention d’agent.
curl -sS -X POST https://api.trustvice.com/api/v1/actions/<action-id> \
-H "Authorization: Bearer $TRUSTVICE_TOKEN" \
-H "X-Workspace-Id: ws_…" \
-H "Content-Type: application/json" \
-d '{ … }'POST /api/v1/actions/<action-id>
Authorization: Bearer <oauth-access-token>
X-Workspace-Id: ws_…
Content-Type: application/json
{ …input fields… }Lisez d’abord ok. En cas de succès, la sortie est dans data ; en cas d’échec, error porte un code lisible par machine et une phrase pour les humains. Un 404 ou 422 métier est la réponse du produit, pas une erreur de transport.
Copié de: /docs/actions
Idempotency-Key.412 confirmation_required.Chaque affirmation ci-dessus vient des docs Trustvice liées sur cette page. Quand une page des docs en dit plus, c’est elle qui fait référence.
Traitez 412 confirmation_required : obtenez un jeton de confirmation et rejouez l’appel avec X-Trustvice-Confirmation.
Un court e-mail quand nous ajoutons des recettes. Rien d’autre, et désabonnement possible depuis chaque message.
Un endpoint POST par action enregistrée, avec le même comportement en REST et en MCP. Les docs listent chaque action avec son entrée et ses permissions.