Référence APISupprimer un intake
DELETE/v1/intakes/{id}

Supprimer un intake

Supprime ou archive un intake. Les dépôts déjà reçus restent accessibles via l'historique du compte, et la clé publishable est révoquée immédiatement.

3 min de lectureTélécharger en PDF

Réponse exemple

{
"id": "int_4f2a9c1b",
"object": "intake",
"deleted": true
}

La suppression d'un intake retire le point de dépôt de votre catalogue et coupe immédiatement la possibilité pour vos déposants d'y envoyer de nouveaux fichiers. Les dépôts déjà reçus, eux, ne disparaissent pas : ils restent consultables dans l'historique de votre compte, et leurs URL de téléchargement présignées continuent de fonctionner tant que vous possédez la phrase secrète qui protège l'enveloppe E2E. Cette opération demande le scope <code>intake_write</code> et porte sur un identifiant <code>in_…</code>. Selon la configuration de votre compte, l'intake est purement supprimé (cas par défaut), ou archivé pour conserver les références sans accepter de nouveaux envois. Dans les deux cas, la réponse renvoie l'enveloppe standard de suppression avec <code>deleted: true</code>.

DELETE/v1/intakes/{id}Supprime ou archive un intake. Les dépôts déjà reçus restent accessibles via l'historique du compte.

Authentification et scope

L'appel doit être effectué côté serveur avec une clé secrète <code>cof_live_</code>, <code>cof_test_</code> ou <code>cof_sandbox_</code>, présentée dans l'en-tête <code>Authorization: Bearer …</code>. La clé publishable <code>cip_…</code> est strictement réservée au navigateur et sera rejetée. Le scope <code>intake_write</code> est obligatoire : une clé limitée à <code>intake_read</code> renverra une erreur <code>403 forbidden</code>.

Paramètres

L'endpoint n'attend aucun corps de requête. Le seul paramètre est l'identifiant de l'intake, transmis dans le chemin de l'URL. L'en-tête <code>Idempotency-Key</code> est accepté pour rejouer en toute sécurité un appel après une coupure réseau.

ParamètreEmplacementTypeDescription
idpathstringIdentifiant de l'intake à supprimer, sous la forme in_xxx. Obligatoire.
AuthorizationheaderstringBearer suivi de la clé secrète. Obligatoire.
Idempotency-KeyheaderstringChaîne de 8 à 255 caractères qui garantit qu'un appel rejoué ne provoque pas d'effet de bord. Optionnel.

Codes de statut

Une suppression réussie renvoie un code 200 et le corps standard de suppression. Les erreurs courantes concernent un identifiant inexistant, une clé sans le scope requis ou une clé invalide.

CodeSignificationCause typique
200okL'intake a été supprimé ou archivé. Le corps renvoie deleted: true.
401unauthorizedClé absente, invalide ou révoquée.
403forbiddenLa clé ne porte pas le scope intake_write.
404not_foundAucun intake ne correspond à l'identifiant fourni sur ce compte.
409conflictL'intake est déjà supprimé ou en cours d'archivage.
429rate_limitedQuota dépassé. Consulter Retry-After avant de réessayer.

Exemple de requête

L'appel est court : un verbe DELETE, l'identifiant de l'intake et la clé secrète. Vous pouvez exécuter l'opération depuis votre back office, depuis un script de maintenance ou depuis un outil d'administration interne.

curl -X DELETE https://api.coffrify.com/v1/intakes/in_2sKp9Rt7xV \
-H "Authorization: Bearer $COFFRIFY_API_KEY" \
-H "Idempotency-Key: delete-in_2sKp9Rt7xV-20260611"

Exemple de réponse

La réponse suit le format standard des suppressions de l'API : l'identifiant de la ressource, son type d'objet et un drapeau <code>deleted</code>. Aucun autre champ n'est renvoyé, car l'intake n'est plus accessible via les endpoints de lecture.

{
"id": "in_2sKp9Rt7xV",
"object": "intake",
"deleted": true
}

Erreurs

Toutes les erreurs renvoient un objet JSON contenant <code>code</code>, <code>message</code> et <code>request_id</code>. Le <code>request_id</code> est précieux pour le support, conservez-le dans vos journaux applicatifs.

{
"code": "not_found",
"message": "No intake matches in_2sKp9Rt7xV on this account.",
"request_id": "req_01HZQ7M9X4WJ4R5C9T6K8FH2YP"
}

Effet sur les ressources liées

  • La clé publishable <code>cip_…</code> rattachée à l'intake est révoquée immédiatement, le widget de dépôt cesse d'accepter de nouveaux envois.
  • Les origines déclarées dans <code>allowed_origins</code> ne sont plus servies par CORS sur les routes de dépôt.
  • Les dépôts déjà reçus restent listés dans l'historique du compte et conservent leurs URLs présignées (<code>download_url</code>, <code>download_expires_in</code> 300 s) lors de chaque relecture.
  • L'enveloppe E2E (clé symétrique encapsulée, IV par fichier) reste attachée à chaque dépôt. Le déchiffrement demeure possible côté propriétaire de la clé privée.
  • Aucune métadonnée du dépôt n'est altérée, que <code>metadata_policy</code> ait été <code>allow</code> ou <code>strip</code>.

Idempotence

En fournissant un en-tête <code>Idempotency-Key</code>, vous pouvez rejouer l'appel après une coupure réseau sans risque : la deuxième tentative renverra le même corps que la première, sans déclencher une seconde suppression. Une clé d'idempotence est conservée 24 heures et doit comporter de 8 à 255 caractères. Réutiliser la même clé avec un identifiant d'intake différent renvoie une erreur <code>409 conflict</code>.