# Reconnect a broken bank connection
URL: https://www.quiltt.dev/guides/reconnect-broken-connections
Description: Repair Connections that enter a user-repairable error state by prompting your end-user to re-authenticate through the Connector.
Navigation: guides → reconnect-broken-connections
Tags: Guides
Content Length: 6k characters

Connections can sometimes enter an error state that prevents new data from being synced. While some errors are intermittent due to upstream connectivity issues with the institution, Connections can also break due to a simple password change or security upgrade at the bank.
This guide walks you through repairing those Connections by prompting your end-user to re-authenticate through the **Reconnect** Flow.

When Quiltt detects that a Connection can be repaired by user interaction with the Connector, the following occurs:

1. The Connection `status` changes to `ERROR_REPAIRABLE`, firing the `connection.synced.errored.repairable` webhook event.
2. Regular syncing is interrupted and no new data is synced, including associated accounts and transactions, until the Connection is repaired.
3. Account Balance Refreshes and other per-Connection actions in the REST API start returning `403 Forbidden`.
4. To restore syncing, the user completes the **Reconnect** Flow by re-authenticating with their financial institution.

## Prerequisites

- A configured Connector in the [Quiltt Dashboard](https://dashboard.quiltt.dev).
- One of the [Connector SDKs](/connector/sdk) integrated into your application.
- The Connection ID of the Connection you want to repair. You can capture this from [Webhooks](/webhooks), a [GraphQL subscription](/api/graphql/subscriptions), or by polling the Connection status.

## Implement the reconnect flow

To allow your end-user to repair the Connection, pass the Connection ID to the Connector SDK. See the following examples and the relevant [SDK docs](/connector/sdk) for platform-specific instructions.

On launching the Connector, your user is automatically prompted to re-authenticate to their institution using the current upstream provider (such as MX, Finicity, or Plaid). Once they have successfully re-authenticated, the Connection resumes syncing. You can track the Connection status via webhooks, GraphQL subscription, or by polling.

If a Connection repeatedly returns to an error state, inspect its [Remote Data](/api/remote-data) to see the provider's error code and message, then review [Troubleshooting Connection Errors](/api/connections#troubleshooting-connection-errors) for next steps and support escalation guidance.

### Examples

Code Examples:

  ```html
    [" quiltt-connection="<CONNECTION_ID>">
      Reconnect]
    ```
  ```tsx
    import {QuilttButton} from '@quiltt/react'

    export const App = () => {
      return (
        

QuilttButton:
"
          connectionId="<CONNECTION_ID>"
          // See the JavaScript API for the full list of available callbacks
          onExitSuccess={(metadata) => [console.log('Reconnected: ', metadata.connectionId)]}
        >
          Reconnect

      )
    }
    ```
  ```tsx
    import {QuilttConnector} from '@quiltt/react-native'

    export const ConnectorScreen = ({navigation}) => {
      return (
        <QuilttConnector
          connectorId="<CONNECTOR_ID>"
          connectionId="<CONNECTION_ID>"
          appLauncherUrl="<YOUR_HTTPS_APP_LINK>"
          // See the JavaScript API for the full list of available callbacks
          onExitSuccess={(metadata) => [console.log('Connected ' + metadata.connectionId)]}
        />
      )
    }
    ```

## Track when a Connection is repaired

### Client-side Connector events

When the user successfully completes the flow, the Connector `exited.successful` event fires. You can attach a callback with the JavaScript API or use the `onExitSuccess` prop on the React component. The `connectionId` is passed to the callback as metadata, alongside the `connectorId` and `profileId`.

See the [JavaScript API guide](/connector/javascript) for more information about the event.

### Server-side webhooks

To notify your server when a Connection needs to be repaired, subscribe to the `connection.synced.errored.repairable` event via [Webhooks](/webhooks).

When the Connection successfully syncs, a `connection.synced.successful` event fires, and the Connection status changes to `SYNCED`.

### GraphQL subscriptions

You can also subscribe to real-time updates on the Connection status with the [`connectionSynced`](/api/graphql/subscriptions) GraphQL Subscription. You can use this approach client-side or server-side.

## Verify the flow in Sandbox

To test the flow, place `SANDBOX` Connections into a user-repairable state using the [`connectionSimulateError` GraphQL mutation](/api-reference/graphql#mutation-connectionSimulateError).

You can call the mutation in the GraphQL Explorer from [the Quiltt Dashboard](https://dashboard.quiltt.dev), or by calling the Profile GraphQL API.

You can simulate an error in the [Quiltt Hub demo](https://demo.quiltthub.com) to see what the experience is like for the user.

Info:
Note that today in `DEMO` and `SANDBOX` environments only, Finicity Connections enter `DISCONNECTED` status and not `ERROR_REPAIRABLE`.

These Connections can still be passed to the [Reconnect Flow](/guides/reconnect-broken-connections) to be reconnected by the end-user.

## Request and response

Code Examples:

  ```graphql
    mutation SimulateError {
      connectionSimulateError(input: [id: "conn_14TJiFDKRJlPiBHuukUIlXZ"]) {
        success
        record [id
          status]
      }
    }
    ```
  ```json
    {
      "data": {
        "connectionSimulateError": {
          "success": true,
          "record": ["id": "conn_14TJiFDKRJlPiBHuukUIlXZ",
            "status": "ERROR_REPAIRABLE"]
        }
      }
    }
    ```

## Reconnect `DISCONNECTED` Connections

In addition to repairing connections that enter an `ERROR_REPAIRABLE` state, you can use **Reconnect** to "revive" connections that were previously put in a `DISCONNECTED` state. This can be used to support migrating connections between different providers.

With a `DISCONNECTED` Connection, the end-user sees a prompt to authenticate into the Connection's institution using the best-suited provider provisioned on the Connector. Once the user has successfully authenticated, Quiltt creates a new Connection, and any relevant data from the `DISCONNECTED` Connection is transferred to the new Connection.

Since a new Connection ID is generated, listen to the `onExitSuccess` callback to capture the new ID and, if your implementation requires it, register it with your backend.