Connexions bancaires
Les liens entre une entreprise et ses banques, ouverts par une page de consentement hébergée par l'agrégateur et complétée par un humain dans un navigateur. Une connexion n'est pas un compte bancaire, les comptes apparaissent sous elle après une synchronisation. Le statut n'avance que sur preuve durable - un événement reçu de l'agrégateur ou une synchronisation explicite - jamais sur le retour du navigateur depuis la page de consentement.
Lister les connexions bancaires d'une entreprise
Retourne les connexions bancaires de l'entreprise, de la plus récente à la plus ancienne. Une connexion n'est pas un compte bancaire - les comptes apparaissent sous elle après une synchronisation et sont exposés par les points d'accès dédiés aux comptes bancaires.
Ouvrir une session de consentement
Ouvre une session de consentement et retourne la connexion en `pending` avec une `consent_url`. **Un `201` signifie qu'une session existe, jamais qu'une banque est connectée.** Un humain doit ouvrir `consent_url` dans un navigateur ; il n'existe pas de connexion bancaire sans navigateur. Interrogez `GET /api/v1/bank_connections/{id}` après le retour de l'utilisateur - un `connected` signifie qu'un événement ou une synchronisation l'a confirmé, ce que la redirection ne fait jamais.
Lire une connexion bancaire
Retourne une connexion bancaire. C'est le point à interroger après le retour d'un utilisateur depuis la page de consentement, car `status` ne passe à `connected` qu'une fois qu'un événement ou une synchronisation a confirmé la banque.
Débrancher une connexion bancaire
Arrête l'accès du fournisseur et fait passer la connexion en `disconnected`. Ce n'est PAS un point d'accès de suppression de données. Les comptes, opérations et écritures comptables déjà importés sont conservés, et la connexion elle-même reste lisible. Pour reprendre, ouvrez une nouvelle session de consentement avec `POST /api/v1/bank_connections/{id}/reconnect`.
Reprendre une connexion bancaire
Ouvre une NOUVELLE session de consentement pour une connexion qui existe déjà, typiquement après un `expired` ou un `error`. Le statut de la connexion ne change PAS sur cet appel - une nouvelle session est une intention, pas une preuve, donc `status` n'avance toujours que sur un événement ou une synchronisation. Un humain doit ouvrir `consent_url` dans un navigateur, exactement comme à la première connexion. Aucun `user_email` n'est attendu ici, le parcours de reprise du fournisseur identifiant l'item plutôt qu'une personne.