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.
List a company's bank connections
Returns the company's bank connections, newest first. A connection is not a bank account - accounts arrive under it from a sync and are exposed by the bank accounts endpoints.
Open a hosted consent session
Opens a consent session and returns the connection in `pending` with a `consent_url`. **A 201 means a session exists, never that a bank is connected.** A human must open `consent_url` in a browser; there is no headless bank connection. Poll `GET /api/v1/bank_connections/{id}` after the user returns - `connected` there means a webhook or a sync confirmed it, and the provider's redirect never does.
Retrieve a bank connection
Returns one bank connection. This is the endpoint to poll after a user comes back from the consent page: `status` advances to `connected` only once a webhook or a sync has confirmed the bank.
Disconnect a bank connection
Stops provider access and moves the connection to `disconnected`. This is NOT a data-deletion endpoint: the accounts, operations and accounting entries already imported are retained, and the connection itself remains readable. To resume, open a new consent session with `POST /api/v1/bank_connections/{id}/reconnect`.
Reconnect a bank connection
Issues a NEW consent session for a connection that already exists, typically after `expired` or `error`. The connection's own status does NOT change on this call - a new session is an intention, not evidence, so `status` still advances only on a webhook or a sync. A human must open `consent_url` in a browser, exactly as on the first connection. No `user_email` is taken here: the provider's manage-an-existing-item flow identifies the item, not a person.