Laissez votre agent demander avant de dépenser : des approbations par lien

Les agents ne devraient pas approuver leurs propres remboursements

Dès qu’un agent peut effectuer des remboursements, acheter des choses ou accorder des accès, quelqu’un demandera « qui a dit oui ? ». La réponse ne peut pas être « le modèle a décidé ». Vous voulez qu’une personne approuve, vous voulez savoir laquelle, et vous voulez que l’agent attende, et non qu’il devine, quand personne ne répond.

Les personnes qui devraient approuver ne sont souvent pas dans votre outil de chat : un responsable financier sur son téléphone, le manager d’un client, le propriétaire d’une petite entreprise. Il leur faut un lien ouvrable n’importe où, pas une licence sur votre logiciel.

Une demande, plusieurs approbateurs

Une approbation est un createRequest avec mode: "approval", un motif, et les personnes qui décident. Chaque personne reçoit son propre lien, si bien que chaque décision lui est attribuée :

{
  "mode": "approval",
  "title": "Refund #4821",
  "requester": "Ava (the Acme refunds agent)",
  "audience": { "kind": "named", "recipients": [
    { "name": "John Smith", "email": "john@acme.com" },
    { "name": "Martin Carpenter", "email": "martin@acme.com" },
    { "name": "Emily Lee", "email": "emily@acme.com" }
  ] },
  "approval": {
    "reason": "Refund order #4821, $1,200",
    "detail": "Customer reported a damaged item. Photos in ticket T-1042.",
    "policy": "majority",
    "showOthers": "names",
    "verify": "email"
  },
  "expiresIn": "24h",
  "webhookUrl": "https://example.com/hooks/runitby",
  "metadata": { "orderId": "4821" }
}

Les options qui comptent

• policy détermine combien d’approbations il faut : "any", "all", "majority" ou un nombre. Le verdict arrive dès qu’il est acquis, sans attendre tout le monde.
• verify: "email" oblige chaque personne à confirmer un code à 6 chiffres envoyé à sa propre adresse avant que les boutons fonctionnent. Un lien transféré ne peut pas décider à sa place. À utiliser pour l’argent, les accès ou les suppressions.
• showOthers permet à chaque approbateur de voir où en sont les autres, par nom ou sous forme de totaux.
• options remplace Approuver et Refuser par jusqu’à quatre libellés, comme « Approuver avec modifications ». Le premier compte comme une approbation.
• allowComment permet d’expliquer sa décision ; les commentaires reviennent avec elle.

Agir sur le verdict, jamais sur le silence

Quand la règle est satisfaite, votre webhook reçoit request.completed avec un verdict : "approved", "declined" ou "expired" (getStatus renvoie la même chose). Si personne ne décide avant l’expiration de la demande, le verdict est expired. Il n’existe aucun cas où l’absence de réponse devient un oui. Avec Builder et Pro, un agent connecté en MCP n’a pas besoin du webhook : il s’abonne à la demande, est prévenu quand le verdict tombe et effectue le remboursement dans la même session.

// Your webhook handler, after checking the X-Runitby-Signature header
if (event.event === 'request.completed') {
  if (event.verdict === 'approved') await refund(event.metadata.orderId)
  else await tellCustomer(event.metadata.orderId, event.verdict)
}

Vérifiez toujours la signature du webhook avant d’agir : c’est un HMAC-SHA256 du corps brut avec le secret de signature de votre compte. La documentation propose une vérification prête à l’emploi.

Bonnes habitudes

• Mettez le montant et la commande dans reason. C’est ce que les gens lisent en premier, sur un petit écran.
• Fixez un expiresIn adapté à la décision. Un remboursement peut attendre un jour ; l’approbation d’un déploiement, probablement pas.
• Utilisez metadata pour transporter vos propres identifiants, afin que le gestionnaire de webhook sache quoi faire sans recherche.
• Appelez remind si une échéance approche. Il renvoie un e-mail aux personnes en attente, au plus une fois par jour chacune.

Vous comparez cela aux approbations Slack ou aux boîtes de relecture ? Voir Run it by face aux outils d’approbation.