Requête exemple
Réponse exemple
Cette route unifiée tranche une demande d'approbation workspace en attente (status = pending) en l'approuvant ou en la refusant. Elle centralise la logique de gouvernance partagée : principe des quatre yeux (un demandeur non-propriétaire ne peut pas approuver sa propre demande), exemption du propriétaire du workspace (owner-exempt), double journalisation (audit dédié coffrify_approval_audit + chaîne d'audit signée coffrify_audit_log), notification in-app best-effort du demandeur, et propagation métier. Quand la demande visait un transfert (type = transfer ou transfer_approval), la décision est répercutée sur coffrify_transfers.approval_status afin que la pipeline d'envoi la voie. Une approbation génère en outre un token de réversibilité valable 5 minutes.
Authentification
Cette route exige une clé API valide disposant du scope workspace:manage. La clé doit par ailleurs porter un contexte utilisateur, car le decided_by enregistré et l'application du principe des quatre yeux reposent sur l'identité du décideur.
Corps de la requête
| Champ | Type | Requis | Description |
|---|---|---|---|
| decision | string | Oui | Décision à appliquer. Valeurs acceptées : approve ou reject. Toute autre valeur renvoie 400 validation_error. |
| decision_reason | string | null | Conditionnel | Motif de la décision. Obligatoire (non vide) lorsque decision = reject, sinon facultatif. Enregistré dans decision_note et propagé à l'audit et à la notification du demandeur. |
| note | string | null | Non | Alias legacy de decision_reason, accepté en parallèle. Si decision_reason est absent, c'est note qui est utilisé. |
L'identifiant de la demande est passé dans le chemin (/v1/approvals/{id}/decide). Un id manquant dans l'URL renvoie 400 validation_error.
Réponse
En cas de succès, la réponse est l'objet ApprovalRecord mis à jour, renvoyé directement (sans enveloppe). Les champs clés sont status (passé à approved ou rejected), decided_by (l'utilisateur décideur), decided_at (horodatage de la décision), decision_note (motif normalisé, null si vide), ainsi que type, resource_id et sensitivity qui qualifient la demande. Pour une demande de type transfert, coffrify_transfers.approval_status est également mis à jour côté serveur.
Erreurs
| Code | Quand | Résolution |
|---|---|---|
| 400 validation_error | id absent du chemin, decision différent de approve/reject, motif manquant sur un reject, ou clé API sans contexte utilisateur. | Vérifiez l'URL, fournissez une decision valide, ajoutez un decision_reason pour un refus et utilisez une clé liée à un utilisateur. |
| 403 forbidden | Auto-approbation interdite (quatre yeux : le demandeur ne peut approuver sa propre demande) ou demande issue du propriétaire du workspace (owner-exempt). | Faites trancher la demande par un autre membre habilité ; une demande de l'owner n'a pas à être approuvée par un tiers. |
| 404 not_found | Aucune demande avec cet id dans le workspace de la clé. | Vérifiez l'identifiant et que la demande appartient bien au workspace courant. |
| 409 conflict | La demande n'est plus en attente (déjà approved, rejected, expired ou revoked). | Aucune action : la décision est définitive. Relisez la demande pour connaître son statut final. |
| 429 rate_limited | Quota de requêtes du workspace dépassé sur les endpoints d'écriture. | Respectez l'en-tête Retry-After et lissez vos appels. |
| 500 internal_error | Échec inattendu de la mise à jour en base. | Réessayez ; si l'erreur persiste, contactez le support avec le request_id. |
Voir aussi
GET/v1/approvalsLister les demandes d'approbation du workspace et filtrer celles en attente.POST/v1/approvals/{id}/approveRoute legacy d'approbation, qui proxie désormais la même logique unifiée.POST/v1/approvals/{id}/rejectRoute legacy de refus, conservée pour la rétrocompatibilité.