# MariaDB MariaDB

Source: https://userguide.qualytics.io/source-datastore/datastore/jdbc/maria-db/

Adding and configuring a MariaDB connection within Qualytics empowers the platform to build a symbolic link with your schema to perform operations like data discovery, visualization, reporting, syncing, profiling, scanning, anomaly surveillance, and more.

This documentation provides a step-by-step guide on how to add MariaDB as a source datastore in Qualytics. It covers the entire process, from initial connection setup to testing and finalizing the configuration. A MariaDB datastore can also be the place Qualytics writes to; see [Use as an Enrichment Datastore](https://userguide.qualytics.io/source-datastore/datastore/jdbc/maria-db/#use-as-an-enrichment-destination).

By following these instructions, enterprises can ensure their MariaDB environment is properly connected with Qualytics, unlocking the platform's potential to help you proactively manage your full data quality lifecycle.

![mariadb-connection-form](https://userguide.qualytics.io/assets/source-datastores/datastore/jdbc/maria-db/overview/mariadb-connection-form.png)

Let’s get started 🚀

## MariaDB Setup Guide

Qualytics connects to MariaDB through the **MariaDB JDBC driver**. It uses standard JDBC metadata APIs to discover databases, tables, columns, and primary keys. MariaDB uses the same permission model as MySQL: the database name you provide in the connection form is the scope for all operations.

### Minimum MariaDB Permissions (Source Datastore)

| Permission | Purpose |
| --- | --- |
| `SELECT` | Read data from all tables for profiling and scanning |
| `SHOW VIEW` | Read view definitions for metadata discovery |
| `PROCESS` | View active queries (used by the JDBC driver for connection metadata) |

### Additional Permissions for an Enrichment Datastore

When MariaDB is used as an enrichment datastore, the following additional permissions are required so Qualytics can write its outputs, which are named from the linked source's prefix (for example `_tpch_failed_checks`):

| Permission | Purpose |
| --- | --- |
| `CREATE` | Create enrichment outputs |
| `ALTER` | Modify enrichment table schemas during version migrations |
| `INSERT` | Write anomaly records, scan results, and check metrics |
| `UPDATE` | Update enrichment records during rescans |
| `DELETE` | Replace records when a run overwrites an output |
| `DROP` | Replace an output when a run overwrites it or its schema changes. Unlinking never removes written data |

### Example: Source Datastore User (Read-Only)

Replace `<database_name>` and `<password>` with your actual values.

```sql
-- Create a dedicated read-only user
CREATE USER ‘qualytics_read’@’%’ IDENTIFIED BY ‘<password>’;

-- Grant read access to all tables and views
GRANT SELECT, SHOW VIEW ON <database_name>.* TO ‘qualytics_read’@’%’;

-- Grant the global PROCESS privilege (required by the JDBC driver for connection metadata)
GRANT PROCESS ON *.* TO ‘qualytics_read’@’%’;

-- Apply the changes
FLUSH PRIVILEGES;
```

### Example: Enrichment Datastore User (Read-Write)

```sql
-- Create a dedicated read-write user
CREATE USER ‘qualytics_readwrite’@’%’ IDENTIFIED BY ‘<password>’;

-- Grant full data manipulation and table management
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, SHOW VIEW ON <database_name>.* TO ‘qualytics_readwrite’@’%’;

-- Grant the global PROCESS privilege (required by the JDBC driver for connection metadata)
GRANT PROCESS ON *.* TO ‘qualytics_readwrite’@’%’;

-- Apply the changes
FLUSH PRIVILEGES;
```

> **Note**
>
> Qualytics automatically filters out system databases (`information_schema`, `mysql`, `performance_schema`, `sys`) during schema discovery. You do not need to restrict access to these databases manually.

### Troubleshooting Common Errors

| Error | Likely Cause | Fix |
| --- | --- | --- |
| `Access denied for user` | Incorrect username, password, or the user does not have access from the connecting host | Verify credentials and ensure the user is created with `’%’` or the specific Qualytics host IP |
| `Host is not allowed to connect` | The MariaDB server rejects connections from the Qualytics host IP | Create the user with `’qualytics_read’@’<qualytics_ip>’` or use `’%’` for any host |
| `SELECT command denied to user` | The user lacks `SELECT` on the target database | Run `GRANT SELECT ON <database_name>.* TO ‘<user>’@’%’` |
| `CREATE command denied to user` | The enrichment user lacks `CREATE` on the database | Run `GRANT CREATE ON <database_name>.* TO ‘<user>’@’%’` |
| `SSL connection is required` | The MariaDB server enforces SSL but the connection is not configured for it | Enable SSL in the connection parameters or configure the MariaDB user to not require SSL |

### Detailed Troubleshooting Notes

#### Authentication Errors

The error `Access denied for user` indicates that the credentials are incorrect or the user does not have access from the connecting host.

Common causes:

- **Incorrect password**: the password does not match the one set for the user.
- **Host restriction**: the user was created with a specific host (e.g., `'user'@'localhost'`) but Qualytics connects from a different IP.
- **User does not exist**: the username was misspelled or was never created.

> **Note**
>
> MariaDB differentiates users by both username and host. `'qualytics'@'localhost'` and `'qualytics'@'%'` are treated as two separate users with potentially different passwords and permissions.

#### Permission Errors

The error `SELECT command denied to user` means the user authenticated successfully but lacks the necessary grants on the target database.

Common causes:

- **Missing `SELECT` grant**: the user does not have `SELECT` on the target database.
- **Wrong database**: the user has permissions on a different database than the one specified in the connection form.
- **Grant not flushed**: after running `GRANT` statements, `FLUSH PRIVILEGES` was not executed.

#### Connection Errors

The error `Host is not allowed to connect` means the MariaDB server rejects the connection from the Qualytics host IP.

Common causes:

- **User host restriction**: the user was created with `'user'@'localhost'` instead of `'user'@'%'`.
- **Firewall or network**: a firewall is blocking connections on port 3306.
- **Bind address**: MariaDB is configured to listen only on `127.0.0.1` (`bind-address` in `my.cnf`).

> **Tip**
>
> Start by confirming credentials are valid (authentication errors), then verify database permissions (permission errors), and finally check network connectivity (connection errors).

## Add a Source Datastore

A source datastore is a storage location Qualytics connects to so it can profile, scan, and monitor data. Adding MariaDB as a source lets Qualytics query it through the MariaDB JDBC driver and run quality operations on the tables it discovers.

Before you start, review the [Minimum MariaDB Permissions](https://userguide.qualytics.io/source-datastore/datastore/jdbc/maria-db/#minimum-mariadb-permissions-source-datastore) the connecting user needs.

### Field reference

The **Add Datastore** page shows the sections below when MariaDB is selected. When reusing an existing connection, the **Connection Properties** and **Secrets Management** sections come already filled in and read-only: Qualytics has already validated those credentials, so you fill in only the **Location** and the **General** fields. To change a saved connection's credentials, edit the connection through the [Manage Connections](https://userguide.qualytics.io/settings/connections/manage-connections/) page; edits there apply to every datastore that reuses the connection.

#### Connection Properties

These fields define the MariaDB server Qualytics connects to and the account it connects with. They belong to the connection: when reusing an existing connection, they come already filled in and read-only.

| Field | Required | Type | Description |
| --- | --- | --- | --- |
| **Connection Name** | Yes | Text | A label for the saved connection (e.g., `acme_mariadb_reporting`), so other datastores can reuse it later. |
| **Host** | Yes | Text | The hostname or address of the MariaDB server. |
| **Port** | Yes | Number | The port the MariaDB instance listens on. Defaults to `3306`. |
| **User** | Yes | Text | The MariaDB account Qualytics connects as. |
| **Password** | Yes | Text | The password for that account. |
| **Max Parallelization** | No | Number | Caps how many queries Qualytics runs at the same time against a datastore reached through this connection, from 1 to 100. Leave it empty for no explicit limit. The cap applies per datastore, so datastores sharing this connection each get their own allowance. Sits in the collapsed **Advanced** section of the form. See [Max Parallelization](https://userguide.qualytics.io/source-datastore/datastore/connection/how-it-works/#max-parallelization). |

#### Secrets Management

This group is optional: use it only if you want Qualytics to pull credentials from a secrets manager instead of typing them into the form. Turn on **HashiCorp Vault** to show the fields below. Despite the label, any secrets manager that exposes a compatible REST API works, not only HashiCorp Vault; see [HashiCorp Vault](https://userguide.qualytics.io/source-datastore/datastore/connection/hashicorp-vault/deep-dive/introduction/). It also belongs to the connection: read-only when reusing an existing connection.

| Field | Required | Type | Description |
| --- | --- | --- | --- |
| **Login URL** | Yes | Text | The full URL of the login endpoint (e.g., `https://vault.example.com/v1/auth/approle/login`). With Vault namespaces, add the namespace after `/v1/`, as in `/v1/<namespace>/auth/approle/login`. |
| **Credentials Payload** | Yes | Text | A JSON body containing the credentials Vault expects (e.g., `{"role_id":"...","secret_id":"..."}`). |
| **Token JSONPath** | Yes | Text | The JSONPath that extracts the client token from Vault's response. Defaults to `$.auth.client_token`. |
| **Secret URL** | Yes | Text | The full URL of the secret, including `https://` and the host (e.g., `https://vault.example.com/v1/secret/data/mariadb`). With Vault namespaces, add the namespace after `/v1/`. |
| **Token Header Name** | Yes | Text | The HTTP header name used to send the token. Defaults to `X-Vault-Token`. |
| **Data JSONPath** | Yes | Text | The JSONPath that extracts the key/value pairs from Vault's response. Use `$.data.data` for a KV version 2 secret (its API path contains `/data/`) and `$.data` for KV version 1 or the database secrets engine. The form pre-fills `$.data`. |

> **Note**
>
> Reference a key from the secret in any **Connection Properties** or **Authentication** field with `${key}`, for example `${password}`. Write it with braces (`${key}`, never `$.key`) and match the key name's case. Qualytics resolves it each time the connection is opened, so a changed value takes effect on the next connection. Setup steps, the namespace rule, and a troubleshooting page are on the [HashiCorp Vault](https://userguide.qualytics.io/source-datastore/datastore/connection/hashicorp-vault/deep-dive/introduction/) pages.

#### Location

Pick the database or databases Qualytics should read from. You fill these in on both flows.

| Field | Required | Type | Description |
| --- | --- | --- | --- |
| **Database** | Yes | Option | One or more databases to read from. Each database you pick becomes its own Qualytics datastore. Click the refresh icon to load the ones visible to the account. |

> **Note: No separate schema step**
>
> MariaDB treats a database as the schema, so there is no catalog selection before it. Selecting more than one database creates one source datastore per database, named from the **Name Template**. See [Multi-Schema Source Datastore Creation](https://userguide.qualytics.io/source-datastore/datastore/multi-schema/overview/) for details.

> **Note: System databases**
>
> The `information_schema`, `mysql`, `performance_schema`, and `sys` databases are left out of discovery, so they do not appear in the list.

#### General

Common fields for every source datastore, shown below the **Location** section. You fill these in on both flows.

| Field | Required | Type | Description |
| --- | --- | --- | --- |
| **Name Template** | No | Text | Defines the naming pattern for each source datastore being created. Use `{{schema}}` as a placeholder that gets replaced with the actual database name (e.g., `maria_{{schema}}` becomes `maria_sales`). Left empty, the datastore is named from the connection name and the database. |
| **Group** | No | Option | Organizes your datastores under a shared group in the navigation tree. Select an existing group or create a new one with the **Add New Group** toggle. |
| **Teams** | Yes | Option | Select one or more teams to associate with this source datastore. |
| **Initiate Sync** | No | Checkbox | Automatically sync the datastore to detect containers and fields after creation. |

Below the form, an information banner lists the **Public addresses** and **Private addresses** your datastore connections originate from. Allow the ones that match your network setup through your security groups or firewall rules; see [How Connections Work](https://userguide.qualytics.io/source-datastore/datastore/connection/how-it-works/#finding-the-addresses-to-allow) for where the addresses come from.

### Steps

There are two ways to set up the connection: reuse a connection you already saved (**Existing Connection**) or create a new one from scratch (**New Connection**). The tabs below walk through each option; pick the one you want to follow. Each field is described in the [Field reference](https://userguide.qualytics.io/source-datastore/datastore/jdbc/maria-db/#source-field-reference) above.

**Tab: New Connection**

**Step 1**: Navigate to the **Datastores** page.

**Step 2**: Click the **Add**  button at the top-right corner and choose **Source** .

**Step 3**: The **Add Datastore** page opens.

**Step 4**: Select **New Connection** next to the **Search**  field.

**Step 5**: Select **MariaDB** from the connector grid. Use the search field to filter connectors by name.

**Step 6**: Fill in the **Connection Properties**: the **Connection Name**, **Host**, **Port**, **User**, and **Password**.

**Step 7**: Optionally, expand **Secrets Management** to retrieve credentials from a secrets manager.

**Step 8**: Fill in the **Location** fields (**Database**) and the **General** fields.

**Step 9**: Click **Test connection**. A success message confirms that the connection has been verified.

> **Info**
>
> The **Finish** and **Next** buttons stay disabled until the connection test passes on the current values. If the test fails, see [Troubleshooting Common Errors](https://userguide.qualytics.io/source-datastore/datastore/jdbc/maria-db/#troubleshooting-common-errors).

**Step 10**: Click **Finish** to create the datastore.

> **Tip**
>
> To link a destination so Qualytics can write anomalies and metadata from the first operation, click **Next** instead of **Finish**. See [Use as an Enrichment Datastore](https://userguide.qualytics.io/source-datastore/datastore/jdbc/maria-db/#use-as-an-enrichment-destination) below.

**Step 11**: A success dialog confirms that your datastore has been added. Click **Go to your datastore** to open its page.

**Tab: Existing Connection**

**Step 1**: Navigate to the **Datastores** page.

**Step 2**: Click the **Add**  button at the top-right corner and choose **Source** .

**Step 3**: The **Add Datastore** page opens.

**Step 4**: Select **Existing Connection** next to the **Search**  field.

**Step 5**: Select the saved MariaDB connection from the grid. Use the search field to filter connections by name. The **Connection Properties** and **Secrets Management** sections come already filled in and read-only.

> **Tip: Start a new connection from this one**
>
> To use the selected connection as a starting point for a brand-new connection instead, click the **Duplicate as a new connection**  button on the selected connection. The form switches to **New Connection** mode with the connection's settings already filled in for you to adjust.

**Step 6**: Fill in the **Location** fields (**Database**) and the **General** fields. These are the only fields left to fill in.

**Step 7**: Click **Test connection**. A success message confirms that the connection has been verified.

> **Info**
>
> The **Finish** and **Next** buttons stay disabled until the connection test passes on the current values. If the test fails, see [Troubleshooting Common Errors](https://userguide.qualytics.io/source-datastore/datastore/jdbc/maria-db/#troubleshooting-common-errors).

**Step 8**: Click **Finish** to create the datastore.

> **Tip**
>
> To link a destination so Qualytics can write anomalies and metadata from the first operation, click **Next** instead of **Finish**. See [Use as an Enrichment Datastore](https://userguide.qualytics.io/source-datastore/datastore/jdbc/maria-db/#use-as-an-enrichment-destination) below.

**Step 9**: A success dialog confirms that your datastore has been added. Click **Go to your datastore** to open its page.

## Use as an Enrichment Datastore

An **enrichment datastore** is where Qualytics writes its findings: scan results, source record examples, remediation snapshots, materialized copies, and exports. Keep it on a dedicated schema or storage path, separate from the source data you govern. When a source datastore is linked to it, that source's writes land there. The destination can share the source's connection when those credentials have the required write access.

To use a MariaDB datastore as a destination, its connection user needs the write grants listed under [Additional Permissions for an Enrichment Datastore](https://userguide.qualytics.io/source-datastore/datastore/jdbc/maria-db/#additional-permissions-for-enrichment-destination). Then link it from the datastore that will write to it: open its **Settings**  menu, click **Enrichment** , and either pick the MariaDB datastore under **Use existing** or create it there under **Add new**. The same choice is offered in the second step of the Add Datastore page. The flow is the same for every connector and is documented once, in [Link an Enrichment Destination](https://userguide.qualytics.io/source-datastore/enrichment-datastore/how-tos/link-enrichment/) and [Link Enrichment on Datastore Creation](https://userguide.qualytics.io/source-datastore/enrichment-datastore/how-tos/link-during-creation/).

The rest of this section covers only what is specific to MariaDB: the fields you fill in when creating the destination on MariaDB from inside that dialog. For what Qualytics writes and how the outputs are named, see [Enrichment Outputs](https://userguide.qualytics.io/source-datastore/enrichment-datastore/deep-dive/tables/).

### Field reference

The **Enrichment Destination** step shows the sections below when MariaDB is selected. When reusing an existing connection, the **Connection Properties** and **Secrets Management** sections come already filled in and read-only.

#### Connection Properties

These fields define the MariaDB server Qualytics connects to and the account it connects with. They are the same fields as on the source datastore flow, repeated here so this section stands on its own.

| Field | Required | Type | Description |
| --- | --- | --- | --- |
| **Connection Name** | Yes | Text | A label for the saved connection (e.g., `acme_mariadb_enrichment`), so other datastores can reuse it later. |
| **Host** | Yes | Text | The hostname or address of the MariaDB server. |
| **Port** | Yes | Number | The port the MariaDB instance listens on. Defaults to `3306`. |
| **User** | Yes | Text | The MariaDB account Qualytics connects as. |
| **Password** | Yes | Text | The password for that account. |
| **Max Parallelization** | No | Number | Caps how many queries Qualytics runs at the same time against a datastore reached through this connection, from 1 to 100. Leave it empty for no explicit limit. The cap applies per datastore, so datastores sharing this connection each get their own allowance. Sits in the collapsed **Advanced** section of the form. See [Max Parallelization](https://userguide.qualytics.io/source-datastore/datastore/connection/how-it-works/#max-parallelization). |

#### Secrets Management

This group is optional: use it only if you want Qualytics to pull credentials from a secrets manager instead of typing them into the form. Turn on **HashiCorp Vault** to show the fields below. Despite the label, any secrets manager that exposes a compatible REST API works, not only HashiCorp Vault; see [HashiCorp Vault](https://userguide.qualytics.io/source-datastore/datastore/connection/hashicorp-vault/deep-dive/introduction/). It also belongs to the connection: read-only when reusing an existing connection.

| Field | Required | Type | Description |
| --- | --- | --- | --- |
| **Login URL** | Yes | Text | The full URL of the login endpoint (e.g., `https://vault.example.com/v1/auth/approle/login`). With Vault namespaces, add the namespace after `/v1/`, as in `/v1/<namespace>/auth/approle/login`. |
| **Credentials Payload** | Yes | Text | A JSON body containing the credentials Vault expects (e.g., `{"role_id":"...","secret_id":"..."}`). |
| **Token JSONPath** | Yes | Text | The JSONPath that extracts the client token from Vault's response. Defaults to `$.auth.client_token`. |
| **Secret URL** | Yes | Text | The full URL of the secret, including `https://` and the host (e.g., `https://vault.example.com/v1/secret/data/mariadb`). With Vault namespaces, add the namespace after `/v1/`. |
| **Token Header Name** | Yes | Text | The HTTP header name used to send the token. Defaults to `X-Vault-Token`. |
| **Data JSONPath** | Yes | Text | The JSONPath that extracts the key/value pairs from Vault's response. Use `$.data.data` for a KV version 2 secret (its API path contains `/data/`) and `$.data` for KV version 1 or the database secrets engine. The form pre-fills `$.data`. |

> **Note**
>
> Reference a key from the secret in any **Connection Properties** or **Authentication** field with `${key}`, for example `${password}`. Write it with braces (`${key}`, never `$.key`) and match the key name's case. Qualytics resolves it each time the connection is opened, so a changed value takes effect on the next connection. Setup steps, the namespace rule, and a troubleshooting page are on the [HashiCorp Vault](https://userguide.qualytics.io/source-datastore/datastore/connection/hashicorp-vault/deep-dive/introduction/) pages.

#### Location

Where Qualytics writes the enrichment tables.

| Field | Required | Type | Description |
| --- | --- | --- | --- |
| **Database** | Yes | Option | The database Qualytics writes the enrichment tables into. Pick exactly one, and make sure the account has write access to it. |

> **Warning**
>
> The account used by an enrichment datastore needs read and write access, while a source datastore needs only read access.

#### General

| Field | Required | Type | Description |
| --- | --- | --- | --- |
| **Name** | Yes | Text | The name of the new datastore. |
| **Teams** | Yes | Option | Select one or more teams to associate with the datastore. |

> **Note: Table prefix**
>
> Qualytics generates a **Prefix** from the source datastore's name for Scan, Remediation, and Materialize outputs. Each source sharing a destination needs a unique prefix. Export tables instead use the normalized datastore name. To change the prefix before creating the datastore, click **Edit prefixes**  in the **Prefix** section of this step.

#### Write Behavior

Whether a Scan also writes a snapshot of the anomalous records, and whether Qualytics profiles the written tables after each write.

| Field | Required | Type | Description |
| --- | --- | --- | --- |
| **Remediation Strategy** | No | Choice | Controls whether and how anomalous source records are written to the enrichment destination. **None** does not write them and is the default, **Append** adds the anomalous records after each scan, and **Overwrite** keeps only the records from the latest scan. |
| **Profile written tables in the enrichment destination** | No | Toggle | On by default. After this datastore writes to the destination, Qualytics always adds the written outputs to the destination, names them, and links them to their source. With this on, Qualytics also profiles them, which types their fields and records row counts, so they are ready to use without a manual step. |

### Steps

Fill in these fields under **Add new**, either in the **Enrichment Destination** dialog of the datastore that will write here or in the second step of the Add Datastore page, then click **Test connection** and save. The steps are the same for every connector: see [Link an Enrichment Destination](https://userguide.qualytics.io/source-datastore/enrichment-datastore/how-tos/link-enrichment/) or [Link Enrichment on Datastore Creation](https://userguide.qualytics.io/source-datastore/enrichment-datastore/how-tos/link-during-creation/).

## API Payload Examples

### Creating a Datastore

This section provides a sample payload for creating a datastore. Replace the placeholder values with actual data relevant to your setup.

#### Endpoint (Post)

`/api/datastores` *(post)*

**Tab: Creating a datastore with a new connection**

```json
    {
        "name": "your_datastore_name",
        "teams": ["Public"],
        "database": "mariadb_database",
        "enrichment_only": false,
        "trigger_sync": true,
        "connection": {
            "name": "your_connection_name",
            "type": "mariadb",
            "host": "mariadb_host",
            "port": 3306,
            "username": "mariadb_username",
            "password": "mariadb_password"
        }
    }
```

**Tab: Creating a datastore with an existing connection**

```json
    {
        "name": "your_datastore_name",
        "teams": ["Public"],
        "database": "mariadb_database",
        "enrichment_only": false,
        "trigger_sync": true,
        "connection_id": 123
    }
```

**Tab: Create a Source Datastore using the CLI**

```bash
# Step 1: Create a Connection
qualytics connections create \
    --type mariadb \
    --name "your_connection_name" \
    --host ${DB_HOST} \
    --port 3306 \
    --username ${DB_USER} \
    --password ${DB_PASSWORD}

# Step 2: Create a Source Datastore
qualytics datastores create \
    --name "your_datastore_name" \
    --connection-name "your_connection_name" \
    --database your_database \
    --schema your_database
```

### Create an Enrichment Datastore

#### Endpoint (Post)

`/api/datastores` *(post)*

This section provides a sample payload for creating an enrichment datastore. Replace the placeholder values with actual data relevant to your setup.

**Tab: Creating an enrichment datastore with a new connection**

```json
    {
        "name": "your_datastore_name",
        "teams": ["Public"],
        "database": "mariadb_database",
        "enrichment_only": true,
        "connection": {
            "name": "your_connection_name",
            "type": "mariadb",
            "host": "mariadb_host",
            "port": 3306,
            "username": "mariadb_username",
            "password": "mariadb_password"
        }
    }
```

**Tab: Creating an enrichment datastore with an existing connection**

```json
    {
        "name": "your_datastore_name",
        "teams": ["Public"],
        "database": "mariadb_database",
        "enrichment_only": true,
        "connection_id": 123
    }
```

**Tab: Create an Enrichment Datastore using the CLI**

```bash
# Step 1: Create a Connection
qualytics connections create \
    --type mariadb \
    --name "your_connection_name" \
    --host ${DB_HOST} \
    --port 3306 \
    --username ${DB_USER} \
    --password ${DB_PASSWORD}

# Step 2: Create an Enrichment Datastore
qualytics datastores create \
    --name "your_datastore_name" \
    --connection-name "your_connection_name" \
    --database your_enrichment_database \
    --schema your_enrichment_database \
    --enrichment-only
```

### Link an Enrichment Destination

#### Endpoint (Patch)

`/api/datastores/{datastore-id}/enrichment/{enrichment-id}` *(patch)*

*Last updated: November 3, 2026.*