Sources : APIs et intégrations

Les outils de la station : les APIs du tenant, et d'autres stations appelées comme des APIs — les intégrations. Chaque opération dit si elle lit ou écrit, son risque et ce qui en sort.

Les APIs

apis:
  - name: stripe
    openapi_url: https://payments.example.fr/openapi.json
    base_url: https://payments.example.fr
    auth: {type: api_key, key_name: Authorization, key_location: header, key_env: STRIPE_KEY}
    operations:
      - {id: getInvoice,     access: read}
      - {id: createRefund,   access: write, risk: high, reversible: false}
      - {id: createCreditNote, access: write, risk: medium, reversible: voidCreditNote}
      - {id: voidCreditNote, access: write, risk: medium}
      - {id: deleteCustomer, access: write, risk: critical, exposed: false}
  - name: zendesk
    auth: {type: oauth2, on_behalf_of: identity}   # l'outil voit QUI agit
    operations:
      - {id: sendReply, access: write, risk: medium, audience: external}

attribut	effet
access	read ou write. Une lecture s'exécute tout de suite ; une écriture est réservée.
risk	low · medium · high · critical. Pèse sur les avertissements (un agent autorisé à soumettre une écriture high).
exposed: false	listée pour être documentée, mais jamais joignable.
audience: external	l'écriture sort de l'organisation (un e-mail au client). Elle ne peut pas porter une donnée confidentielle.
reversible	l'opération qui l'annule, ou false. L'écran d'approbation dit « irréversible » ; au submit, les écritures irréversibles passent en dernier.
auth.on_behalf_of: identity	l'appel porte l'identité de la personne, pas une clé partagée.

Une station comme API

apis:
  - name: fournisseur-materiel
    station: mcp.convoy.sale/materiel-pro/mcp

L'appel passe par l'autre station : ses règles s'appliquent. Notre agent y devient une sous-identité. Les deux journaux partagent un identifiant de corrélation.