Aller au contenu principal
Audact
Explorer un workflow

API · Evidence Vault

Des reçus, récupérables et recalculables.

Hôte d’API public: Opérationnel aujourd’hui

GET https://api.audact.ai/v1/receipts/{call_id}

L’API REST publique sur api.audact.ai/v1. Le serveur MCP a sa propre entrée de registre.

Mesuré le 21 octobre 2026 : GET https://api.audact.ai/v1/health renvoie 200 ; les routes /v1 protégées renvoient 401 avec le corps d’erreur standard. La référence publique à /docs/api-reference liste chaque opération publique.

Pourquoi cet état
Affirmation
Opérationnel aujourd’hui · Early Customer Program
Périmètre
L’API REST publique sur api.audact.ai/v1. Le serveur MCP a sa propre entrée de registre.
Fondement
Mesuré le 21 octobre 2026 : GET https://api.audact.ai/v1/health renvoie 200 ; les routes /v1 protégées renvoient 401 avec le corps d’erreur standard. La référence publique à /docs/api-reference liste chaque opération publique.
Ce que cela n’établit pas
Que chaque opération individuelle a été vérifiée de bout en bout en production.
Ce que vous pouvez obtenir aujourd’hui
L’accès en production s’inscrit dans un contrat payant applicable. Les points d’accès ne sont pas tarifés séparément.
Dernière vérification
21 octobre 2026
Où le vérifier
/apis

Export de production : Opérationnel aujourd’hui · testé à nouveau le 26 août 2026, après le déploiementVérificateur public : Pas encore disponible

Tout ce que les cinq autres points d’accès écrivent arrive ici. Les reçus sont agrégés en une racine de Merkle horaire ; l’agrégat de chaque tenant est une feuille d’une racine inter-tenants. Un reçu isolé est visible dans le produit. L’export de production d’un ensemble de reçus — JSON pour une machine, PDF pour une personne — a fonctionné lors de son nouveau test du 26 août 2026, après le déploiement — cinq appels, trente tours de conversation validés, trente reçus — mesuré sur des appels par navigateur plutôt que sur une ligne téléphonique. Ce que l’enregistrement lui-même vous apporte est inchangé : toute modification ou tout réordonnancement ultérieur est détectable en recalculant par rapport à l’engagement stocké. C’est cela, la propriété, et c’est une affirmation plus faible et plus honnête que le mot auquel la plupart des éditeurs recourent.

GET /v1/receipts/{call_id}

{
  "receipt": {
    "receipt_format_version": "1.0.0",
    "call_id": "7f3c2a1e-0000-4000-8000-000000000000",
    "timestamp": "2026-08-15T10:14:23Z",
    "input_hash": "9b1d…e04a",
    "output_hash": "9b1d…e04a",
    "verdict": "ALLOW",
    "config_version": 12,
    "config_seal_hash": "4c2e…91d0",
    "policy_version": "DE_v1.1.0",
    "evidence_hash": "0b8e…7a13",
    "auth_mechanism": "hmac-sha256",
    "signature": "z3fx…c0de"
  },
  "hmac_valid": true,
  "verifiability": "full"
}

Le reçu tel que le moteur l’émet : JSON, canonicalisé comme décrit sur /receipt-explorer, avant le calcul du code HMAC-SHA256 sous une clé symétrique détenue par Audact — et non une signature à clé publique. `receipt_format_version` nomme le format, de sorte qu’un ancien reçu reste contrôlable lorsqu’il change.

GET /v1/calls + export par appel

# List calls
curl https://api.audact.ai/v1/calls \
  -H "Authorization: Bearer $AUDACT_API_KEY"

# Export one call's Article 50 report (JSON)
curl https://api.audact.ai/v1/calls/7f3c2a1e-0000-4000-8000-000000000000/article50-report \
  -H "Authorization: Bearer $AUDACT_API_KEY"

# PDF variant
curl "https://api.audact.ai/v1/calls/7f3c2a1e-0000-4000-8000-000000000000/article50-report?format=pdf" \
  -H "Authorization: Bearer $AUDACT_API_KEY"

Listez les appels avec GET /v1/calls ; exportez par appel avec GET /v1/calls/{call_id}/article50-report (JSON, ou ?format=pdf). Les racines de Merkle horaires voyagent dans le rapport ; l’agrégat de chaque tenant est une feuille d’une racine inter-tenants.

Ce que vous obtenez

Agrégation de Merkle : les reçus sont agrégés en racines de Merkle horaires ; l’agrégat de chaque tenant est une feuille d’une racine inter-tenants. Les racines sont publiées sur api.audact.ai/v1/metachain.
Opérationnel aujourd’hui
Deux formats d’export à partir d’un même enregistrement : JSON pour une machine, PDF pour une personne. Export de production d’un ensemble de reçus. L’export porte une signature ECDSA ; les reçus qu’il contient portent leur HMAC. La clé publique de l’enveloppe est servie à GET /v1/keys/{kid}.
Opérationnel aujourd’hui
Le pack de preuves mensuel ne fait pas partie de l’offre.
En validation
Un paramètre de conservation des enregistrements par tenant ; effacement cryptographique à la demande via POST /v1/calls/{call_id}/pii/shred et POST /v1/pii/shred.
En tests contrôlés
Des artefacts d’exemple à examiner avant d’écrire une ligne de code.
Opérationnel aujourd’hui
Un vérificateur public, pour une contrepartie sans compte.
Vérificateur public pas encore disponible

Ce qui tient

Trois champs que n’importe qui peut recalculer. Sans clé, sans compte. Un quatrième, contrôlé par rapport à la racine publiée avec la preuve d’inclusion du rapport article 50 de l’appel.

L’empreinte de ce qui est entré, l’empreinte de ce qui est sorti et l’empreinte de l’événement de preuve précédent se recalculent à partir du reçu, du texte sur lequel elles ont été calculées et de l’événement précédent de la chaîne : sans clé, sans compte. Recalculez ces trois-là et toute modification ou tout réordonnancement ultérieur est détectable en recalculant par rapport à l’engagement stocké. Le quatrième, l’inclusion dans la racine de Merkle, se contrôle par rapport à la racine publiée avec la preuve d’inclusion du rapport article 50 de l’appel ; le rapport contient `event_inclusion_proof`, `cross_tenant_proof` et `merkle_root`, et `POST /v1/verify-inclusion` contrôle une preuve de branche sans clé.

Le code d’authentification est d’une tout autre nature. C’est un HMAC-SHA256, calculé avec une clé symétrique détenue par Audact. Ce n’est pas une signature à clé publique et il n’existe pas de clé publique de vérification. Quiconque peut le contrôler peut aussi le produire. Il authentifie ; il n’attribue pas.

Conservation

Un paramètre de conservation par tenant ; effacement cryptographique à la demande.

La conservation se configure par tenant avec le paramètre de conservation des enregistrements. Lorsqu’un enregistrement sort de sa fenêtre, l’effacement est cryptographique et à la demande : POST /v1/calls/{call_id}/pii/shred détruit la clé de la charge utile pour un appel ; POST /v1/pii/shred agit sur une empreinte PII. L’entrée de la chaîne reste, de sorte que la séquence demeure contrôlable alors que le contenu a disparu. C’est ce qui rend une demande d’effacement au titre de l’art. 17 du RGPD compatible avec une chaîne de preuves.

Questions

Un régulateur peut-il contrôler un reçu sans compte Audact ?
Pour les trois champs recalculables, oui : avec le fichier et une fonction de hachage. Le quatrième, l’inclusion de Merkle, se contrôle par rapport à la racine publiée avec la preuve d’inclusion du rapport article 50 de l’appel. Vérificateur public pas encore disponible : les racines sont publiées sur api.audact.ai/v1/metachain, mais un service qui effectue ces étapes à votre place n’existe pas aujourd’hui, et aucune date n’est engagée.
Qu’apporte le PDF de plus que le JSON ?
La lisibilité, rien de plus. Il contient les mêmes champs issus du même enregistrement, mis en page pour quelqu’un qui n’ouvrira pas de terminal.
Que devient la chaîne après une demande d’effacement ?
L’entrée reste et le contenu disparaît. L’effacement est à la demande et cryptographique : POST /v1/calls/{call_id}/pii/shred détruit la clé de la charge utile pour un appel ; POST /v1/pii/shred agit sur une empreinte PII. La séquence et les empreintes concordent toujours alors que les données personnelles sont irrécupérables.

Regardez d’abord l’artefact d’exemple

Un reçu d’exemple au format de production : les champs que le moteur émet, avec des valeurs synthétiques. Les textes d’entrée et de sortie figurent à côté du reçu pour que les empreintes puissent être recalculées ; un reçu de production ne contient que les empreintes.

Recalculez vous-même une chaîne

L’Explorateur de reçus prend une chaîne d’exemple et la parcourt : empreinte d’entrée, empreinte de sortie, empreinte de l’événement de preuve précédent et chemin de Merkle. Dans votre propre navigateur, sans compte.

Ouvrir l’Explorateur de reçus

Pages associées