> For the complete documentation index, see [llms.txt](https://docs.euno.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.euno.ai/sources/custom-integrations/custom-integration/custom-integration-properties-reference.md). # Custom Integration Properties Reference The Custom integration accepts observations for built-in Euno resource types and custom resource types registered for your account. Only a **closed subset** of Euno built-in properties may be set in each observation. If an observation includes a property that is not listed below, the observation is **skipped** and counted in the run report as invalid. For observation structure and upload flows, see [Custom Integration](/sources/custom-integrations/custom-integration.md) and [Handling High Volume of Observations](/sources/custom-integrations/custom-integration/handling-high-volume-of-observations.md). ## Observation shape Each observation is a JSON object with: | Field | Required | Description | | ------------ | -------- | -------------------------------------------------------------------------------------------------------------------------------------- | | `uri` | Yes | Unique identifier for the resource. See [URI structure](/developer-reference/technical-concepts/universal-resource-identifier-uri.md). | | `properties` | Yes | Object containing `type`, `name`, and any optional supported properties below. | ### Example ```json { "uri": "custom.analytics.customer_summary", "properties": { "type": "table", "name": "customer_summary", "description": "Aggregated customer metrics", "database_technology": "snowflake", "tags": ["analytics", "production"], "meta": { "owner": "data-team" }, "explicit_additional_dependencies": [ "custom.analytics.raw_customers" ] } } ``` ## Supported properties | Property | Required | Type | Description | | ---------------------------------- | -------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `type` | **Yes** | string | Built-in Euno resource type such as `table` or `column`, or a custom type registered for your account such as `campaign_view` or `cube_measure`. | | `name` | **Yes** | string | Display name of the resource. | | `description` | No | string | Human-readable description of the resource. | | `raw_code` | No | string | Raw SQL or other source code associated with the resource. | | `qualified_code` | No | string | Code for the resource, fully qualified based on known column schemas and upstream tables. | | `tags` | No | array of strings | Tags applied to the resource. | | `meta` | No | object | Arbitrary key-value metadata (JSON object). | | `database_technology` | No | string | Warehouse or database technology where the resource lives (for example `snowflake`, `bigquery`, `redshift`). | | `table_dependencies` | No | array of strings | Upstream resource URIs for **resource-level** lineage on any type **except** `table` and `column`. Each entry must be a valid URI string. See [Lineage properties](#lineage-properties). | | `explicit_additional_dependencies` | No | array of strings | Upstream URIs for **`type: "table"`** and **`type: "column"`** only. On tables, merged into resource-level lineage; on columns, merged into field-level lineage. Do **not** use on other types. See [Lineage properties](#lineage-properties). | | `upstream_fields` | No | array of strings | Upstream field URIs for **field-level** lineage on field-like resources other than `column` (for example `dbt_metric`, `dbt_dimension`, `snowflake_metric`, `snowflake_dimension`, `looker_measure`, `looker_dimension`, `omni_measure`, `omni_dimension`). Each entry must be a valid URI string. Do **not** use on `type: "column"`; use `explicit_additional_dependencies` instead. See [Lineage properties](#lineage-properties). | | `parent_container` | No | string | URI of the parent container of the resource. Creates a `has parent` / `has child` relationship in the graph. The value must be a valid URI string. | | `parent_container_name` | No | string | Display name of the parent container. Normally derived automatically from the parent's `name` once the parent is observed; setting it directly on the child is only useful when the parent observation lags or is omitted. | | `container_chain` | No | array of objects | Ancestry of the resource from immediate parent outward. Each element is a `{uri, name, native_type, normalized_type}` object. | | `icon_url` | No | string | URL to an icon image for the resource. See [Custom type icons](#custom-type-icons) below. | ## Required properties on every observation Every observation must include both `type` and `name` in its `properties` object. Observations missing either property are skipped and reported in the run report. Observations with allowed properties but invalid values (for example a malformed `icon_url`, or `tags` provided as a string instead of an array) are also skipped and counted as invalid. Custom resource types must be registered before observations use them. Built-in types such as `table` and `column` do not need registration. If an observation uses an unregistered custom type, Euno skips that observation and records the unknown type in the run report. Register custom types with `POST /accounts/YOUR_ACCOUNT_ID/resource_types` before sending observations. ## Lineage properties Custom integration supports **three** lineage input properties. Which one to use depends on the resource `type` and whether the lineage is resource-level or field-level: | Resource `type` | Lineage kind | Property to set | Relationship created in Euno | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | ---------------------------------- | ---------------------------- | | `table` | Resource-level | `explicit_additional_dependencies` | `has upstream` | | `column` | Field-level | `explicit_additional_dependencies` | `has upstream_fields` | | **Any other type** (for example `campaign_view`, `acme_transform_script`) | Resource-level | `table_dependencies` | `has upstream` | | **Any field-like type other than `column`** (for example `dbt_metric`, `dbt_dimension`, `snowflake_metric`, `snowflake_dimension`, `looker_measure`, `looker_dimension`, `omni_measure`, `omni_dimension`) | Field-level | `upstream_fields` | `has upstream_fields` | {% hint style="info" %} **Rules** * **`explicit_additional_dependencies`** — use **only** on `table` and `column`. On tables, do **not** use `table_dependencies`; it will not persist as lineage. * **`table_dependencies`** — use on **every other type** for resource-level lineage. Do **not** use `explicit_additional_dependencies` on other types; it is stored but **does not create lineage edges**. * **`upstream_fields`** — use for field-level lineage on field-like types **other than** `column`. For `type: "column"`, use `explicit_additional_dependencies` instead — Euno recomputes `upstream_fields` for column-typed resources from `explicit_additional_dependencies` (and inferred code-based column dependencies), so a value set directly on a column would be overwritten. {% endhint %} For relationship semantics in Euno, see [Relationships](/developer-reference/technical-concepts/relationships.md). ### `explicit_additional_dependencies` Use **only** when `type` is `table` or `column`: ```json "explicit_additional_dependencies": [ "custom.analytics.staging_orders", "custom.acme_elt.enrich_orders" ] ``` ### `table_dependencies` Use when `type` is **anything other than** `table` or `column` and you want resource-level lineage: ```json "table_dependencies": [ "custom.raw.orders", "custom.raw.customers" ] ``` ### `upstream_fields` Use on field-like types **other than** `column` to declare field-level lineage directly: ```json { "uri": "custom.analytics.revenue", "properties": { "type": "dbt_metric", "name": "revenue", "upstream_fields": [ "custom.analytics.orders.amount", "custom.analytics.orders.tax" ] } } ``` ## Parent/child relationships Use `parent_container` to attach a resource to its parent in the graph. The parent itself must also be observed (in the same run or a previous one) so the edge can resolve. `container_chain` optionally captures the ancestry from the immediate parent outward, as a list of `{uri, name, native_type, normalized_type}` objects. Example — a `dbt_metric` child observation, the `semantic_model` parent observation, and the ancestry: ```json [ { "uri": "custom.acme.revenue_model", "properties": { "type": "semantic_model", "name": "revenue_model" } }, { "uri": "custom.acme.revenue_model.revenue", "properties": { "type": "dbt_metric", "name": "revenue", "parent_container": "custom.acme.revenue_model", "container_chain": [ { "uri": "custom.acme.revenue_model", "name": "revenue_model", "native_type": "semantic_model", "normalized_type": "semantic_model" } ] } } ] ``` Notes: * `parent_container_name` is normally derived automatically from the parent's `name` once the parent is observed; supply it directly on the child only when the parent observation lags or is omitted. * Every entry in `container_chain` must include all four keys (`uri`, `name`, `native_type`, `normalized_type`); the `uri` must be a valid URI. Malformed entries cause the whole observation to be skipped and reported in the run report. ## Custom type icons Use `icon_url` to supply a custom icon for resources whose `type` is not a built-in Euno resource type (for example `acme_transform_script`). ```json { "uri": "custom.acme_elt.enrich_orders", "properties": { "type": "acme_transform_script", "name": "enrich_orders.py", "icon_url": "https://airflow.apache.org/images/airflow-icon.svg" } } ``` Requirements: * The URL must use `http://` or `https://` and be at most 2048 characters. * For the icon to render in the Euno UI, the URL path should end with a common image extension such as `.svg`, `.png`, `.jpg`, `.gif`, or `.webp`. * Host the image at a URL your Euno users can reach (public HTTPS is typical). * `table`, `database`, and `database_schema` resources use the warehouse icon from `database_technology` instead of `icon_url`. Set `icon_url` on each resource that should display the icon (typically every resource of the same custom type uses the same URL). ## Related documentation * [Custom Integration setup](/sources/custom-integrations/custom-integration.md) * [Example: Homegrown ELT Pipeline](/sources/custom-integrations/custom-integration/example-homegrown-elt-pipeline.md) * [Handling High Volume of Observations](/sources/custom-integrations/custom-integration/handling-high-volume-of-observations.md) * [Universal Resource Identifier (URI)](/developer-reference/technical-concepts/universal-resource-identifier-uri.md) * [Relationships](/developer-reference/technical-concepts/relationships.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.euno.ai/sources/custom-integrations/custom-integration/custom-integration-properties-reference.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.