Requête exemple
Réponse exemple
Cet endpoint crée un <b>intake</b>, le point d'entrée d'une drop box sécurisée que vos clients utiliseront pour vous transmettre des fichiers chiffrés de bout en bout. Vous recevez en retour l'objet intake complet et, pour la première et unique fois, une <b>publishable_key</b> (préfixe <code>cip_</code>) à intégrer dans votre site ou votre application. Cette clé publique sert à initialiser le widget de dépôt côté navigateur, sans jamais exposer votre clé secrète serveur.
POST/v1/intakesCrée une nouvelle drop box de réception E2E et renvoie sa clé publique d'intégration.Authentification et scope
Cet endpoint requiert une clé secrète serveur (<code>cof_live_</code>, <code>cof_test_</code> ou <code>cof_sandbox_</code>) transmise via l'en-tête <code>Authorization: Bearer</code>. Le scope <code>intake_write</code> doit être attribué à la clé. Nous recommandons fortement de transmettre un en-tête <code>Idempotency-Key</code> (8 à 255 caractères) pour rendre la création rejouable sans risque de doublon en cas de coupure réseau.
Paramètres du corps
Seul le champ <code>name</code> est obligatoire. Les autres paramètres affinent le comportement du widget, la politique de métadonnées et les origines autorisées à monter le formulaire.
| Paramètre | Type | Requis | Description |
|---|---|---|---|
| name | string | oui | Nom interne de l'intake, visible dans votre console (par exemple « Dépôt dossier successoral »). |
| slug | string | non | Identifiant URL court. Généré automatiquement à partir de name si omis. |
| allowed_origins | string[] | non | Domaines autorisés à monter le widget (par exemple ["https://cabinet-martin.fr"]). Vide = toutes origines refusées en production. |
| metadata_policy | string | non | Vaut allow (métadonnées en clair côté serveur) ou strip (jamais stockées). Défaut : strip. |
| reference_required | boolean | non | Si true, le déposant doit fournir une référence opaque (numéro de dossier). Défaut : false. |
Exemple de requête
L'exemple ci-dessous crée un intake nommé « Dépôt clients » restreint au domaine du cabinet, avec une référence de dossier obligatoire et une politique de métadonnées stricte.
Exemple de réponse
La réponse contient l'objet intake et le champ <code>publishable_key</code>. Stockez cette clé dans un coffre, elle ne sera jamais réaffichée par l'API.
Codes de statut
| Code | Signification | Cause typique |
|---|---|---|
| 201 | Created | L'intake est créé, la publishable_key est dans la réponse. |
| 401 | invalid_api_key | La clé fournie dans l'en-tête Authorization est inconnue, expirée ou révoquée. |
| 403 | scope_missing | La clé est valide mais ne porte pas le scope intake_write. |
| 422 | validation_error | Un champ est invalide : name vide, slug déjà pris, metadata_policy hors valeurs autorisées, origine mal formée. |
| 429 | rate_limited | Quota atteint. Consultez Retry-After et X-RateLimit-Reset. |
Exemple d'erreur 422
Toutes les erreurs suivent la même structure JSON, avec un <code>code</code> machine, un <code>message</code> lisible et un <code>request_id</code> à fournir au support en cas de besoin.
Étapes suivantes
Une fois l'intake créé, deux chemins s'offrent à vous. En no-code, ajoutez la balise script Coffrify à votre site et appelez <code>Coffrify.mountIntake</code> avec la <code>publishable_key</code>. En headless, instanciez <code>new Coffrify.Intake({ publishableKey })</code> côté navigateur puis appelez <code>intake.upload(files, options)</code> pour piloter le dépôt depuis votre propre interface. Côté serveur, listez les dépôts via <code>GET /v1/intakes/{id}/documents</code>.