Concepts

Modèle multi-tenant

MEA est strictement multi-tenant. Chaque clé d’API externe appartient à un seul tenant. Toutes les requêtes sont automatiquement filtrées par le tenant_id de la clé : il est impossible de lire ou d’écrire les données d’un autre tenant, et aucun paramètre ne permet de franchir cette frontière.

Contrainte de chiffrement de bout en bout (E2EE)

MEA chiffre les documents côté client (zero-knowledge) : le serveur ne possède aucune clé utilisateur et ne voit jamais le texte en clair.

Conséquences pour l’API externe :

• Un document marqué is_encrypted=true renvoie 403 DOCUMENT_E2EE_PROTECTED au téléchargement de son contenu (GET /documents/{id}/content). Les métadonnées restent lisibles.
• Les documents créés via l’API externe sont toujours stockés non chiffrés (is_encrypted=false, created_by_user_id=null). L’API externe est un canal machine-to-machine, hors du périmètre zero-knowledge.

Si votre intégration doit récupérer le contenu de documents chiffrés, le déchiffrement doit avoir lieu côté client humain via l’application MEA — il n’existe pas de contournement serveur par conception.

Limitation de débit

Une limitation de débit native s’applique à /api/external/v2 :

• Fenêtre fixe de 1 minute, partitionnée par clé d’API.
• 60 requêtes/minute par défaut (configurable par clé).
• Dépassement → 429 RATE_LIMIT_EXCEEDED.

Mettez en place un backoff exponentiel côté client et regroupez vos appels (pagination large plutôt que multiples petites requêtes).

Conventions de codes d’erreur

Les codes suivent le format {DOMAINE}_{DESCRIPTION} en SCREAMING_SNAKE_CASE. Chaque code est stable (les clients en dépendent) et mappe vers exactement un statut HTTP.

Toujours router votre logique sur le champ error.code, jamais sur le message (susceptible d’être traduit ou reformulé).

Voir le guide d’intégration pour des exemples complets.