Managing Extended Connectors (DCT)

Overview

Most database connectors in DCT use a built-in database type — Oracle, MS SQL Server, PostgreSQL, MySQL, MariaDB, DB2, Sybase, and their variants. For these, DCT already ships the JDBC driver and you only supply connection details.

An extended connector (database_type = EXTENDED) lets you mask a data source that DCT does not support out of the box. Instead of a built-in driver, an extended connector references a custom JDBC driver that you upload and register with DCT first. Once that driver exists, an extended connector behaves like any other database connector — you add it to a rule set and run masking, discovery, and profiling jobs against it exactly as you would for a built-in type.

Use an extended connector when:

Your data source is a database DCT does not natively support.
You need a specific driver version or a commercial (e.g. CData) JDBC driver.
Your source requires custom pre/post-job behavior supplied by a driver support plugin (constraints, triggers, indexes, etc.).

Object model & dependencies

Setting up an extended connector means creating up to four objects, in a fixed order, because each one depends on the output of the previous step:

  POST /v3/masking-file-uploads   (driver .zip, multipart)
        │  returns file_reference_id
        │
        │   ┌─ (optional) POST /v3/masking-plugins (plugin_type=DRIVER_SUPPORT)
        │   │      returns driver support plugin id  ──► driver_support_id
        │   │
        │   ├─ (CData only) POST /v3/masking-file-uploads (license .bin, multipart)
        │   │      returns file_reference_id          ──► license_file_id
        ▼   ▼
  POST /v3/compliance-jdbc-drivers   { name, class_name, file_reference_id,
                                       driver_support_id?, license_file_id? }
        │  returns compliance JDBC driver id
        ▼
  POST /v3/connectors   { type: DATABASE, database_type: EXTENDED,
                          compliance_jdbc_driver_id, hostname, port, ... }
        │  returns connector id
        ▼
  POST /v3/connectors/{id}/test      → verify connectivity
        │
        ▼
  (add connector to a rule set — unchanged from any database connector)

Object	API surface	Depends on	Required?
File upload (driver .zip)	`/v3/masking-file-uploads`	—	Yes
Driver support plugin	`/v3/masking-plugins` (plugin_type=DRIVER_SUPPORT)	—	Optional
License entitlement (.bin)	`/v3/masking-file-uploads`	—	CData drivers only
Compliance JDBC driver	`/v3/compliance-jdbc-drivers`	driver .zip file upload (+ optional plugin, license)	Yes
Extended connector	`/v3/connectors`	compliance JDBC driver	Yes

Key ordering rule — you must upload the driver file before you can create the compliance JDBC driver, and you must create the compliance JDBC driver before you can create the extended connector that references it.

Prerequisites & limitations

Driver format: The JDBC driver must be a Type 4, pure-Java driver. Package the driver .jar (and any dependency jars) into a single .zip file before uploading.
Class name: You must know the fully-qualified JDBC driver class (for example org.postgresql.Driver).
Permissions (RBAC): Creating and managing these objects requires the corresponding DCT object-type permissions — COMPLIANCE_JDBC_DRIVER, CONNECTOR, plugin, and masking-file permissions. Verify your API key's role grants create/read/update/delete on these object types.
CData drivers: additionally require a license entitlement (.bin) — see step 3 below.
Job orchestrator: As with any DCT-managed connector, an extended connector is associated with a job orchestrator (job_orchestrator_id).

1. Upload the JDBC driver file

Upload the driver .zip as a masking file. This is a multipart/form-data request with a file part (plus optional description and tags).

POST /v3/masking-file-uploads      (multipart/form-data)
  file        = <your-driver>.zip
  description = "PostgreSQL 42.7 JDBC driver"     (optional)

Response (201):

{
  "file": {
    "id": "f_6af70917922542af89ea6e7c31e80205",
    "filename": "postgresql-42.7.zip",
    "file_reference_id": "delphix-file://upload/f_6af70917922542af89ea6e7c31e80205/postgresql-42.7.zip",
    "file_size": 1043210,
    "file_checksum": "…",
    "created_date": "2026-07-06T14:22:10Z"
  }
}

Keep the file_reference_id — you pass it to the compliance JDBC driver in step 4. (The id, f_..., is also accepted anywhere a file reference is expected.)

2. (Optional) Install a driver support plugin

A driver support plugin lets DCT perform database-specific operations around a masking job — disabling/re-enabling constraints, triggers, and indexes, etc. Delphix ships several built-in driver support plugins (source in the masking-driver-support repository); you can also install your own.

Driver support plugins are installed through the masking-plugins API with plugin_type = DRIVER_SUPPORT. First upload the plugin file (step 1 pattern), then:

POST /v3/masking-plugins
{
  "file_id": "f_<plugin-file-upload-id>",
  "plugin_type": "DRIVER_SUPPORT",
  "name": "my-driver-support",            // optional; overrides manifest name
  "description": "Custom driver support"  // optional
}

Response (201):

{ "id": "<driver-support-plugin-id>", "job": { "id": "…", "status": "…" } }

Keep the returned id — pass it as driver_support_id when creating the compliance JDBC driver in step 4. If you don't need custom pre/post-job behavior, skip this step and omit driver_support_id.

3. (CData only) Upload the license entitlement

Commercial CData JDBC drivers require a license entitlement file (.bin). Upload it the same way as the driver file in step 1:

POST /v3/masking-file-uploads      (multipart/form-data)
  file = Salesforce.bin

Response (201) returns a file_reference_id, e.g. delphix-file://upload/f_6af70917922542af89ea6e7c31e80205/Salesforce.bin.

Keep this value — pass it as license_file_id in step 4. license_file_id is required for CData drivers and rejected for non-CData drivers. Only supply it when registering a CData driver.

4. Create the compliance JDBC driver

Register the uploaded driver as a compliance JDBC driver, referencing the file_reference_id from step 1 (and, if applicable, driver_support_id from step 2 and/or license_file_id from step 3).

POST /v3/compliance-jdbc-drivers
{
  "name": "PostgreSQL 42.7",
  "class_name": "org.postgresql.Driver",
  "file_reference_id": "delphix-file://upload/f_6af70.../postgresql-42.7.zip",
  "description": "PostgreSQL JDBC driver",   // optional
  "driver_support_id": null,                 // optional; from Step 2
  "license_file_id": null                    // CData only; from Step 3
}

Response (201):

{ "id": "<compliance-jdbc-driver-id>", "job": { "id": "…", "status": "…" } }

Field reference:

Field	Required	Notes
`name`	Yes	Display name, 1–255 chars.
`class_name`	Yes	Fully-qualified JDBC driver class.
`file_reference_id`	Yes	The uploaded driver .zip reference from step 1.
`driver_support_id`	No	Associated driver support plugin (step 2).
`license_file_id`	No	.bin entitlement reference. Required for CData, rejected otherwise.
`description`	No	Free text.
`tags`	No	DCT tags.

Keep the returned id — this is the compliance_jdbc_driver_id for your connector.

5. Create the extended connector

Create a database connector with database_type = EXTENDED, referencing the compliance JDBC driver from step 4. All other fields (host, port, credentials, orchestrator) are the same as any database connector.

POST /v3/connectors
{
  "name": "my-extended-connector",
  "type": "DATABASE",
  "database_type": "EXTENDED",
  "compliance_jdbc_driver_id": "<compliance-jdbc-driver-id>",   // or the driver's name
  "hostname": "db.mycompany.co",
  "port": 5432,
  "username": "masking_user",
  "password": "••••••••",
  "job_orchestrator_id": "<orchestrator-id>",
  "enable_logger": false          // EXTENDED-only; enables extended driver logging
}

Response (201):

{ "id": "<connector-id>", "job": { "id": "…", "status": "…" } }

compliance_jdbc_driver_id accepts either the driver's ID or its name, and is required when database_type = EXTENDED. It cannot be cleared on a later update.
enable_logger is used exclusively for extended connectors to turn on extended driver logging for troubleshooting.

Test the connection

Verify connectivity against the saved connector:

POST /v3/connectors/{connectorId}/test

Response (200):

{ "status": "SUCCEEDED", "message": "…", "job": { "id": "…", "status": "…" } }

You can also test connection details before saving, using POST /v3/connectors/test with the same body as the create request. This is handy for validating driver/credentials while iterating.

Using the connector

Once the extended connector tests successfully, there is nothing extended-connector-specific left to do. Add it to a rule set (POST /v3/rule-sets with connector_id), fetch table names, and run compliance, discovery, and profiling jobs exactly as you would for a built-in database connector. The custom driver is transparent to all downstream masking workflows.

Managing these objects

All four object types support full CRUD plus list/search and tagging. Common operations:

Operation	Compliance JDBC driver	Extended connector	Driver support plugin	File upload
List	`GET /v3/compliance-jdbc-drivers`	`GET /v3/connectors`	`GET /v3/masking-plugins`	`GET /v3/masking-file-uploads`
Get one	`GET …/{driverId}`	`GET …/{connectorId}`	`GET …/{maskingPluginId}`	`GET …/{maskingFileId}`
Search	`POST …/search`	`POST …/search`	`POST …/search`	`POST …/search`
Update	`PATCH …/{driverId}`	`PATCH …/{connectorId}`	`PATCH …/{maskingPluginId}`	—
Delete	`DELETE …/{driverId}`	`DELETE …/{connectorId}`	`DELETE …/{maskingPluginId}`	`DELETE …/{maskingFileId}`
Tags	`…/{id}/tags`, `…/{id}/tags/delete`	same	same	same

Deletion ordering follows the dependency chain in reverse: a compliance JDBC driver that is still referenced by a connector cannot be removed until the connector is deleted (or repointed).

Notes

Asynchronous creates. Creating a compliance JDBC driver, connector, or plugin returns a job object. The object is fully ready once its job reaches a completed state; poll the job (GET /v3/jobs/{jobId}) if you need to gate subsequent steps in automation.
Extended logging. Set enable_logger: true on the connector to capture extended driver logs when diagnosing connectivity or masking issues.

Last updated

Oct 8, 2026

Overview

Object model & dependencies

Prerequisites & limitations

1. Upload the JDBC driver file

2. (Optional) Install a driver support plugin

3. (CData only) Upload the license entitlement

4. Create the compliance JDBC driver

5. Create the extended connector

Test the connection

Using the connector

Managing these objects

Notes