SQLink integration reference

This reference describes documented interfaces for developers integrating lineage. Verify paths and parameters against the target deployment. Examples contain no real hosts, credentials, or object IDs.

DAM integration

DAM can use SQLink management for spaces, preprocessing, and namespaces. Metadata-object lineage and the standalone Data Lineage module have different licensing scopes; see licenses. Embedding an object lineage view does not grant permissions.

Request conventions

Append the paths below to /sqlink on the deployed service. All listed operations use POST. Requests and responses normally use JSON; uploads use multipart/form-data; template downloads return binary data.

Use deployment-specific unified authentication, including actual headers, token acquisition, and expiry. Distinguish invalid parameters, authentication, missing resources, and service errors. Verify business output even after HTTP success.

Namespaces, tags, and custom relationships

Operation	Path	Request
Create namespace	/dataArea/createDataArea	Body: required name, objectType; optional defaultSchemas
Metadata coverage	/dataArea/getMetadataCoverage	Query: required Long namespaceId
Delete namespaces	/dataArea/deleteDataArea	Body: ID array; related lineage files prevent direct deletion
Create custom lineage	/customLineage/create	Body: required name, edges; optional description; edges contain startId, endId
Tag objects	/tag/addTag	Body: objectId, tagIds, optional propagation
Find tagged objects	/tag/getByTag	Query: required Long tagId

Propagation uses diffusion, direction, and depth. Directions are FORWARD (downstream), BACKWARD (upstream), and ALL. It is disabled by default; define depth and scope before enabling.

Graph, transformation, and impact queries

Operation	Path	Request and result
Query graph	/lineageGraph/query	Body nodes and conditions; returns a subgraph
Get transformations	/lineageGraph/getTransform	Graph conditions and id or queryIds; optional query isGraph
Get impact	/lineageGraph/getImpact	Node, direction, depth, resource types

See query API details for types, defaults, responses, and direction differences. Verify granularity and temporary-object handling; graph and impact contracts differ.

Files, SQL, and broken-lineage jobs

Operation	Path	Request
Upload file	/lineage/uploadLineageFile	Query: required lineageEngine, objectType, folderId; optional defaultSchema, parse; multipart file
Parse SQL	/lineage/parse	Body: required sqlContent; optional defaultSchema, sqlType
Analyze broken lineage	/lineage/executeBrokenLineageJob	Body may limit sourceNamespaces, targetNamespaces, direction

{
  "sqlContent": "INSERT INTO demo_target.orders SELECT order_id FROM demo_source.orders",
  "defaultSchema": "demo_target",
  "sqlType": "DML"
}

Replace example schemas with authorized context. Parsing is separate from executing SQL. After upload, verify file ID, parsing state, report, and object matching.

Scripts and scheduling

Operation	Path	Request
Create preprocessing script	/script/createScript	Body: name, scriptType, objectType, scriptContent; optional enabled
Download script template	/script/exportScriptTemplates	Returns an Excel import template
Create job	/job/createJob	Body: name, binding, schedule, execution class
Run now	/job/runJob	Query jobId; optional descriptor body overriding defaults

scriptType is JAVASCRIPT, REGEX, or LLM. Job creation requires name, bindResourceId, bindResourceType, schedule, and className, with optional description and jobContent. Obtain binding types and execution classes from the supported definition rather than inventing Java names.

Running returns an instance identifier, not completion. Check execution records. Deletion, propagation, upload with parsing, and execution change service data; bound integration tests and avoid resubmitting successful mutations.