> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reconlayer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configuration

> Business setup for import mappings, canonical fields, data sources, organization settings, and access.

Configuration covers everything that shapes how ReconLayer interprets your data and who can act on it. In the dashboard this spans two areas: the **Configuration** page (file mappings, canonical fields, data sources) and the **Settings** page (organization details, workspace access, and user preferences). Both are thin layers over API resources that you can also manage directly.

<Note>
  The dashboard is one consumer of the API. Reconciliation rules, organization settings, member access, and user preferences are all available via dedicated endpoints, so you can manage configuration as code if you prefer.
</Note>

## Configuration page

The page header reads "Configuration" with the description "Business setup for imports, canonical data, and source connectivity." A warning banner explains the current scope:

> Launch scope is limited to import mappings, canonical fields, and source connectivity. Advanced reconciliation rule controls stay hidden until the backend rule engine is fully enabled.

Three tabs are available:

### File mappings

This tab lists your organization's **import profiles** — the field mappings that turn uploaded files into canonical `PaymentIntent` or `FlowLeg` records, loaded via [List import profiles](/api-reference/imports/list-import-profiles) (`GET /v1/import-profiles`).

Each profile shows:

* Its name and `sourceType`
* The number of fields mapped
* An active/inactive badge
* Its field mappings as `sourceColumn -> targetField` pairs

Selecting a profile (if you have `config_edit`) opens an editor where you can change its field mappings, source type, and active status. Saving calls [Update an import profile](/api-reference/imports/update-an-import-profile) (`PATCH /v1/import-profiles/{importProfileId}`), and a profile can be removed via [Delete an import profile](/api-reference/imports/delete-an-import-profile).

The **New import profile** action (also requires `config_edit`) creates a profile via [Create an import profile](/api-reference/imports/create-an-import-profile) (`POST /v1/import-profiles`).

<Tip>
  Prefer deterministic keys for mappings — external reference, provider transfer ID, beneficiary account, and transaction hash — whenever your source files include them. These are the fields the matching engine relies on most.
</Tip>

### Canonical fields

A reference view of the canonical fields that import profiles map into, loaded via [List canonical fields](/api-reference/imports/list-canonical-fields) (`GET /v1/canonical-fields`). Examples include:

| Canonical field      | Belongs to      |
| -------------------- | --------------- |
| `externalReference`  | `PaymentIntent` |
| `sourceAmount`       | `PaymentIntent` |
| `destinationAmount`  | `PaymentIntent` |
| `providerTransferId` | `FlowLeg`       |
| `txHash`             | `FlowLeg`       |
| `beneficiaryAccount` | `PaymentIntent` |

This tab is read-only — it exists so operators building or reviewing an import profile know which target fields are available.

### Data sources

Lists the integrations connected to your organization (for example a PSP like Bridge, an on-chain provider, or a bank statement source), loaded via the integrations API. Selecting **Add a data source** (requires `config_edit`) opens a picker backed by [Get integration catalog](/api-reference/integrations/get-integration-catalog), followed by a connection form. Depending on the provider, connecting a source calls either the generic integration creation endpoint or, for Bridge specifically, the dedicated Bridge integration endpoint ([Create a Bridge integration](/api-reference/integrations/create-a-bridge-integration)).

### Reconciliation rules

A **Reconciliation Rule** controls how the matching engine evaluates a `PaymentIntent` against incoming evidence — amount tolerances, time windows, and SLA thresholds. Rules are managed entirely through the API:

* [List reconciliation rules](/api-reference/reconciliation-cases/list-reconciliation-rules) — `GET /v1/reconciliation-rules`
* [Create a reconciliation rule](/api-reference/reconciliation-cases/create-a-reconciliation-rule) — `POST /v1/reconciliation-rules`
* [Update a reconciliation rule](/api-reference/reconciliation-cases/update-a-reconciliation-rule) — `PATCH /v1/reconciliation-rules/{ruleId}`
* [Delete a reconciliation rule](/api-reference/reconciliation-cases/delete-a-reconciliation-rule) — `DELETE /v1/reconciliation-rules/{ruleId}`

A rule can target a specific combination of `paymentType` and `sourceType`, just `paymentType`, just `sourceType`, or serve as the organization default — resolved in that priority order (most specific first).

Each rule defines:

<AccordionGroup>
  <Accordion title="Matching windows">
    * `amountTolerance` — allowed amount difference for a match
    * `timeWindowMinutes` — maximum time gap between expected and observed activity
    * `expectedCompletionMinutes` — expected end-to-end duration for the route
  </Accordion>

  <Accordion title="SLA thresholds">
    * `delayedSettlementThresholdMinutes`
    * `sourceSlaMinutes`
    * `intermediaryInSlaMinutes`
    * `transferSlaMinutes`
    * `intermediaryOutSlaMinutes`
    * `destinationSlaMinutes`
  </Accordion>

  <Accordion title="Match strategies">
    * `allowProviderIdMatch`
    * `allowTxHashMatch`
    * `allowReferenceExactMatch`
    * `allowAmountAndTimeWindowMatch`
    * `requireAllRequiredLegs`
  </Accordion>
</AccordionGroup>

<Warning>
  A dedicated rule-editing screen exists in the dashboard's codebase but is currently hidden behind a launch-scope flag while the backend rule engine is finished. Until it is enabled, manage reconciliation rules through the API endpoints above. Changing a rule re-evaluates matching for affected open cases.
</Warning>

## Settings page

The Settings page ("Account, login, organization, and workspace preferences for signed-in users") covers identity-and-org-level configuration. It has five tabs: **General**, **Access**, **Notifications**, **Members**, and **Preferences**.

### General — organization settings

Backed by [Get organization settings](/api-reference/settings/get-organization-settings) and [Update organization settings](/api-reference/settings/update-organization-settings):

```
GET /v1/organization-settings
PATCH /v1/organization-settings
```

The form covers:

| Field         | Description                                                   |
| ------------- | ------------------------------------------------------------- |
| `name`        | Organization display name                                     |
| `description` | Free-text description                                         |
| `region`      | Operating region                                              |
| `currency`    | Default currency (`USD`, `EUR`, `GBP`, `MXN`, `BRL`)          |
| `slaProfile`  | Default SLA profile applied where a rule does not override it |
| `retention`   | Data retention period (1, 3, 5, 7, or 10 years)               |

Changes require the `settings_general` permission.

### Access — identity and login

When Clerk-based identity is enabled, this tab shows your login details: primary email, organization, account creation date, and last successful login. MFA and passkey status are displayed, though enabling them currently requires a Clerk plan upgrade and the controls are disabled with an explanatory note.

### Members — workspace access and roles

Backed by the member access API:

* [List workspace roles and member access assignments](/api-reference/settings/list-workspace-roles-and-member-access-assignments) — `GET /v1/member-access`
* [Sync active Clerk members into workspace access assignments](/api-reference/settings/sync-active-clerk-members-into-workspace-access-assignments) — `POST /v1/member-access/sync`
* [Create or upsert a workspace member access assignment](/api-reference/settings/create-or-upsert-a-workspace-member-access-assignment) — `POST /v1/member-access`
* [Update a workspace member access assignment](/api-reference/settings/update-a-workspace-member-access-assignment) — `PATCH /v1/member-access/{accessId}`
* [Delete a workspace member access assignment](/api-reference/settings/delete-a-workspace-member-access-assignment) — `DELETE /v1/member-access/{accessId}`
* [Update workspace role permissions](/api-reference/settings/update-workspace-role-permissions) — `PATCH /v1/member-access/roles/{roleId}`

There are three roles:

| Role         | Who it's for                                                              |
| ------------ | ------------------------------------------------------------------------- |
| `admin`      | Full access (locked — permissions cannot be edited)                       |
| `operations` | Operators who triage cases, run imports, and manage configuration         |
| `read_only`  | Auditors, support, or leadership who need visibility without write access |

Each role maps to a set of permissions grouped as follows:

| Permission group   | Permissions                                                         |
| ------------------ | ------------------------------------------------------------------- |
| Overview and cases | `overview_view`, `cases_view`, `cases_action`, `cases_export`       |
| Imports            | `imports_view`, `imports_upload`, `imports_review`                  |
| Configuration      | `config_view`, `config_edit`                                        |
| Developer          | `developer_view`, `webhooks_manage`, `api_keys_manage`, `logs_view` |
| Audit and settings | `audit_view`, `settings_general`, `settings_notifications`          |
| Members and roles  | `members_invite`, `members_manage`                                  |

Admins have every permission. Operations and read-only roles have an explicit `true`/`false` for each permission, editable (for non-locked roles) through the **Manage roles** modal, which calls [Update workspace role permissions](/api-reference/settings/update-workspace-role-permissions).

<Note>
  Several actions on this tab — inviting members, syncing members from Clerk, and changing roles — require a signed-in user with `members_invite` or `members_manage`, not an API key.
</Note>

### Preferences — per-user settings

Backed by [Get user preferences](/api-reference/settings/get-user-preferences) and [Update user preferences](/api-reference/settings/update-user-preferences):

```
GET /v1/user-preferences/{userId}
PATCH /v1/user-preferences/{userId}
```

Currently this controls UI-level preferences such as font size, persisted per signed-in user.

### Notifications

Configures queue alerts, security alerts, product updates, and a weekly digest. This tab is currently marked as coming soon in the dashboard.

## From here

<CardGroup cols={2}>
  <Card title="List import profiles" icon="code" href="/api-reference/imports/list-import-profiles">
    Manage import mappings programmatically.
  </Card>

  <Card title="List reconciliation rules" icon="sliders" href="/api-reference/reconciliation-cases/list-reconciliation-rules">
    Read and adjust matching tolerances and SLA thresholds.
  </Card>

  <Card title="Get organization settings" icon="building" href="/api-reference/settings/get-organization-settings">
    Read or update organization-level configuration.
  </Card>

  <Card title="List workspace roles and member access assignments" icon="users" href="/api-reference/settings/list-workspace-roles-and-member-access-assignments">
    Manage who can access the workspace and what they can do.
  </Card>
</CardGroup>