> ## Documentation Index > Fetch the complete documentation index at: https://docs.synq.io/llms.txt > Use this file to discover all available pages before exploring further. # GetFolderOf > Given entity ids, return the folder breadcrumb(s) each entity lives in — ordered root first, leaf (immediate parent) last. An entity may appear in more than one hierarchy; the response carries every folder along its containing chain. Compose with `ListMembers` on an entity's immediate parent to list its siblings. ## OpenAPI ````yaml /api-reference/openapi.yaml get /api/entities/folders/v1/folder-of openapi: 3.1.0 info: version: '1.0' title: SYNQ servers: - url: https://developer.synq.io - url: https://api.us.synq.io security: - bearerAuth: [] tags: - name: synq.schedule.v1.ScheduleService description: ScheduleService provides schedule evaluation utilities. - name: synq.platforms.v1.PlatformsService description: PlatformsService is a service for managing Platforms and Integrations. - name: synq.git.commits.v1.CommitsService - name: synq.owners.v1.OwnersService description: |- OwnersService manages owners and their ownerships — the "alert routing as code" surface. An owner is a named responsible party with notification channels (contacts); an ownership assigns a set of assets to an owner and configures the alerts routed to it. Owner is the resource, ownership its sub-resource: an ownership is meaningless without its owner, and deleting an owner deletes its ownerships. Ids are opaque UUIDs supplied by the caller, which makes writes idempotent (a retried create converges instead of duplicating). Mutable fields are optional on the Upsert calls: a set field is written, an omitted field is left unchanged. Pass the `etag` you last read to guard against overwriting a concurrent edit. Related: `synq.dataproducts.v2.DataproductsService` (an ownership can own a whole data product), `synq.alerts.v1.AlertsService` (how the configured alerts are reported), and `synq.users.v1.UsersService` (resolve the users behind `UserContact` and Slack/Teams mentions). - name: synq.queries.v1.QueriesService description: |- QueriesService compiles and evaluates ResolverQL — the compact text query language used across Coalesce Quality to select entities — over the public API. ResolverQL is a string DSL (for example `with_type("TABLE")` or `in_folder(...)`); a structured `synq.queries.v1.Query` is its parsed, machine-readable form. This service is the bridge between the two and the read-only execution surface for both: - `TranslateResolverQl` compiles a ResolverQL expression into a structured `Query` without evaluating it — inspect it, validate it, or reuse it as a filter on another API (entity listing, folder browsing, ...). - `ResolveQuery` compiles a ResolverQL expression (or takes an already-structured `Query`), evaluates it against the catalog, and returns the matched entity ids. This is the general author -> resolve loop. - name: synq.queries.v1.NLQueryService description: >- NLQueryService generates structured Query protos from natural language descriptions using an LLM. - name: synq.integrations.v1.IntegrationsService description: |- IntegrationsService manages connections from Coalesce Quality to your data systems (warehouses, databases, and transformation tools). Concurrency: every integration carries an opaque `etag`. Read it from `GetIntegration` / `ListIntegrations`, then pass it back on `UpdateIntegration` / `DeleteIntegration` to ensure you modify the version you last saw. A stale etag is rejected with ABORTED (HTTP 409). Omit the etag for last-write-wins. Quota: each workspace has a limit on the number of integrations. Creating beyond the limit is rejected with RESOURCE_EXHAUSTED. Secrets: credential fields (passwords, tokens, keys) are write-only. They are masked (returned empty) on every read. On update, omit a secret to keep it, send a new value to rotate it, or send an explicit empty string to clear it (where the field is `optional`). - name: synq.auth.iam.v1.IamService - name: synq.extensions.atlan.provider.v1.AtlanProviderService - name: synq.extensions.atlan.workflows.v1.AtlanWorkflowService - name: synq.extensions.atlan.integrations.v1.AtlanIntegrationService - name: synq.issues.v2.IssuesService description: IssuesService is a service for managing Issues. - name: synq.issues.issues.v1.IssuesService description: IssuesService is a service for managing Issues. - name: synq.alerts.services.v1.AlertsService description: AlertsService provides operations for managing alert configurations. - name: synq.agent.recon.v1.SuiteDeploymentService description: |- SuiteDeploymentService is the platform plane of reconciliation. SuiteConfigService is the developer/authoring sandbox (edit, version, run ad-hoc with your own credentials — preview-only, no Entity, no Run, no Issue). A deployment is what SYNQ actually runs on the workspace's behalf: a frozen snapshot of a suite config, mapped to workspace-level SYNQ integrations, optionally scheduled or triggerable by API. Identity: every deployment has a stable deployment_id (UUIDv7) assigned on first promote. It survives re-promotes, schedule/mapping changes, and pause/resume. Downstream AssetCommand / RunCommand publication keys off deployment_id so Entity identity does not fragment on promote churn. - name: synq.agent.recon.v1.YamlService description: >- YamlService provides stateless conversion between YAML config format and proto. This is useful for UI editors that need to display/edit suite configs as YAML. - name: synq.agent.sre.v1.LlmService description: Service for evaluating LLM requests and producing structured output. - name: synq.agent.sre.v1.TriageService description: >- Service for managing issue triage operations, allowing LLM agents to conclude investigations and record evidence during the triage process. - name: synq.agent.sre.v1.FeatureRequestService description: >- FeatureRequestService allows MCP clients to submit feature requests when users encounter missing capabilities. This is a last-resort service — it should only be used when no existing tool can fulfill the user's request. - name: synq.datachecks.v1.TriggerService description: TriggerService provides synchronous execution of datachecks on entities. - name: synq.datachecks.testsuggestions.v1.TestSuggestionsService - name: synq.entities.executions.v2.EntityExecutionsService description: >- EntityExecutionsService provides read-only access to entity execution history. This service allows customers to retrieve information about all executions that happened on their entities, including execution status, timing, and messages. Use cases: - Retrieve execution history for specific entities - Filter executions by time range, status, or execution type - Get aggregated summaries of execution activity - Track execution trends and patterns - name: synq.datachecks.sqltests.v1.SqlTestsService description: SqlTestsService is a service for managing SqlTests. - name: synq.monitors.info.v1.MonitorInfoService - name: synq.monitors.automated_monitors.v1.DeploymentRulesService - name: synq.monitors.history.v1.HistoryService - name: synq.monitors.custom_monitors.v1.CustomMonitorsService - name: synq.monitors.predictions.v1.MonitorPredictionsService description: Access to anomaly detection model predictions and raw metric timeseries. - name: synq.entities.resolve.v1.IdentifierResolveService description: >- IdentifierResolveService resolves identifiers to their Coalesce Quality paths and identities. - name: synq.entities.coordinates.v1.DatabaseCoordinatesService description: >- DatabaseCoordinatesService is a service for getting database coordinates of Entities. - name: synq.entities.folders.v1.FoldersService description: >- FoldersService discovers and browses the folder / containment hierarchy of the catalog: the roots data hangs from, the sub-folders under any folder, the folders a given entity lives in, and the entities contained in a folder. It is a read / navigation surface, not folder management — there are no create, move, or delete operations. Addressing: every folder has an opaque `folder_entity_id` (round-trip it verbatim) and a structured `FolderRef{root_entity_id, folders[]}` (the human-friendly form). Entities — both folder members and the ids you pass to `GetFolderOf` — are named by their opaque entity id, the same id used across the rest of the entities API. Depth footgun: membership is SHALLOW by default. `Browse` returns only the direct children of a folder, and `ListMembers` returns only the entities placed directly in the folder. Set `deep = true` (or raise `Browse.depth`) to recurse into sub-folders. - name: synq.entities.lineage.v1.LineageService description: |- LineageService allows you to fetch: * Entity level lineage from a starting point of one or more entities. * Column Level lineage from a starting point of multiple columns of a single entity. - name: synq.entities.impact.v1.ImpactService - name: synq.entities.annotations.v1.AnnotationsService description: >- AnnotationsService provides operations for managing and querying entity annotations. Annotations are key-value pairs that can be attached to entities for categorization and filtering. - name: synq.entities.changes.v1.ChangesService description: >- ChangesService provides functionality to track and retrieve all types of changes to data entities. This unified service returns ALL change types for an entity: - Git commits: Changes to code files (dbt models, SQL files) tracked in version control - Schema changes: Database schema modifications (columns added/removed/changed) - SQL definition changes: View/materialized view definition updates detected by Coalesce Quality Changes are returned with structured metadata including: - For git commits: structured statistics (directories, file types, top changes) - For schema changes: detailed column-level diffs - For SQL changes: before/after SQL definitions Use cases: - "What changed in the last week for table X?" → Returns git commits, schema changes, SQL changes - "Show me all commits affecting this dbt model" → Returns git commits with lineage context - "What schema changes happened to this table?" → Returns schema changes detected by Coalesce Quality - name: synq.entities.status.v1.EntityIssuesService description: EntityIssuesService is the service which retrieves entity issues status. - name: synq.entities.status.v1.EntityIncidentsService description: EntityIncidentsService is the service which retrieves entity status. - name: synq.entities.orchestration.v1.OrchestrationService description: >- OrchestrationService provides information about orchestration relationships between entities. This includes relationships between Airflow tasks and transformation models (dbt, SQLMesh), as well as task-to-task dependencies. - name: synq.entities.checks.v1.ChecksCategoriesService description: |- ChecksCategoriesService lets workspace admins set explicit category overrides on individual checks. An explicit category is the authoritative category for a check — it takes precedence over the categories computed by the workspace's categorisation rules. It is a public API so customers can manage check categories programmatically; the same service is also mounted on the internal API. The workspace and the acting identity are always taken from the request context, never from the payload. - name: synq.entities.custom.v1.TypesService description: TypesService is a service for managing custom entity types. - name: synq.entities.custom.v1.EntityExecutionsService - name: synq.entities.custom.v1.EntitiesService description: >- custom.EntitiesService is a service for managing custom entities. Entities can represent various data platform concepts such as services, consumers, applications or data pipelines that are not natively available in Coalesce Quality. Entities are identified by a unique identifier and can be created, updated, read and deleted. - name: synq.entities.custom.v1.FeaturesService - name: synq.entities.custom.v1.GroupsService description: >- It eliminates the need to keep state on client side to remember which assets were already created and which should be deleted. The server will keep track of the current state of the group and client can always send the intended new state. The server will calculate the diff and entities that are no longer present in the group will be removed. Example: 1. group has entities A, B, C at time t1 2. client sends group with entities B, C, D at time t2 3. server will remove entity A from the system and update the current state of the group to B, C, D The service is designed to be idempotent and can be called multiple times with the same state without causing any side effects. - name: synq.entities.custom.v1.RelationshipsService description: >- RelationshipsService allow management of relationships between entities. Relationships can be created, updated, and deleted between 2 custom entities, or between a custom entity and Coalesce Quality native entity.enum There is no option to create relationships between 2 Coalesce Quality native entities (dbt model, BI dashboard, etc.). - name: synq.entities.custom.v1.ChecksRelationshipsService - name: synq.entities.entities.v1.EntitiesService description: EntitiesService is a service for retriving any entity. - name: synq.entities.executions.v1.EntityExecutionsService description: 'Deprecated: Use [synq.entities.custom.v1.EntityExecutionsService] instead' - name: synq.entities.sql_insights.v1.SqlInsightsService description: >- SqlInsightsService exposes analytical information about the SQL used across a workspace's entities. It answers questions such as "which SQL constructs are used in my warehouse, and how often" and "what SQL constructs does this specific entity use", without requiring the caller to re-parse any SQL. - name: synq.entities.schemas.v1.SchemaMismatchesService description: >- SchemaMismatchesService provides access to schema drift information between data platform tables and their definitions (e.g., dbt models). - name: synq.entities.schemas.v1.SchemasService description: EntitiesService is a service for retriving any entity. - name: synq.entities.code.v1.CodeService description: >- CodeService is a service for retrieving code associated with entities in the system. It provides functionality to access and manage code artifacts such as SQL queries, Python scripts, dbt models, and other code configurations that are part of Coalesce Quality entities. - name: synq.entities.constraints.v1.TableConstraintsService description: >- TableConstraintsService provides access to table constraint and index information. - name: synq.ingest.dwh.v1.DwhService - name: synq.ingest.openlineage.v1.OpenlineageService - name: synq.ingest.cloudwatch.v1.CloudwatchService - name: synq.ingest.airflow.v1.AirflowLogsService - name: synq.savedviews.v1.SavedViewsService description: >- SavedViewsService manages saved views — named, reusable selections over your entities (and other surfaces) with display configuration, sharing and per-user pinning. A saved view is owned by the user who created it. It can be kept private, shared with the whole workspace, or granted to specific users. Reads return, for the calling user, how each view relates to them (mine / shared / granted) and what they are allowed to do with it. Workspace administrators can manage any view in the workspace. - name: synq.dataproducts.v2.DataproductsService description: |- DataproductsService manages data products — named, owned groupings of data assets with a membership definition, a priority and an optional folder. Ids are opaque UUIDs supplied by the caller, which makes writes idempotent (a retried create converges instead of duplicating). Mutable fields are optional on Upsert: a field that is set is written, a field that is omitted is left unchanged. Pass the `etag` you last read to guard against overwriting a concurrent edit. A data product is a leaf in the reference graph — its definition may not reference another data product or domain — so membership resolution always terminates. - name: synq.dataproducts.v1.DataproductsService description: DataproductsService can be used to manage data products. - name: synq.incidents.v1.IncidentsService description: IncidentsService is a service for managing Incidents. paths: /api/entities/folders/v1/folder-of: get: tags: - synq.entities.folders.v1.FoldersService summary: GetFolderOf description: |- Given entity ids, return the folder breadcrumb(s) each entity lives in — ordered root first, leaf (immediate parent) last. An entity may appear in more than one hierarchy; the response carries every folder along its containing chain. Compose with `ListMembers` on an entity's immediate parent to list its siblings. operationId: synq.entities.folders.v1.FoldersService.GetFolderOf parameters: - name: entityIds in: query description: >- Opaque entity ids to look up. Ids that do not exist, or that live in no folder, are absent from the response. schema: type: array items: type: string title: entity_ids description: >- Opaque entity ids to look up. Ids that do not exist, or that live in no folder, are absent from the response. responses: '200': description: Success content: application/json: schema: $ref: >- #/components/schemas/synq.entities.folders.v1.GetFolderOfResponse components: schemas: synq.entities.folders.v1.GetFolderOfResponse: type: object properties: breadcrumbsByEntityId: type: object additionalProperties: $ref: >- #/components/schemas/synq.entities.folders.v1.GetFolderOfResponse.Breadcrumbs title: value description: Requested entity id -> its containing breadcrumb(s). title: GetFolderOfResponse additionalProperties: false synq.entities.folders.v1.GetFolderOfResponse.Breadcrumbs: type: object properties: breadcrumbs: type: array items: $ref: >- #/components/schemas/synq.entities.folders.v1.GetFolderOfResponse.Breadcrumb title: Breadcrumbs additionalProperties: false description: >- All breadcrumbs for one entity. Most entities have a single breadcrumb; an entity placed in several hierarchies has one per hierarchy. synq.entities.folders.v1.GetFolderOfResponse.Breadcrumb: type: object properties: folders: type: array items: $ref: '#/components/schemas/synq.entities.folders.v1.Folder' title: Breadcrumb additionalProperties: false description: >- One containing breadcrumb: the folders from a root down to (and including) the entity's immediate parent, ordered root first. synq.entities.folders.v1.Folder: type: object properties: folderEntityId: type: string description: >- Opaque, authoritative id of this folder. Round-trip it verbatim as the `parent` of `Browse` or the `folder` of `ListMembers`; do not parse it. It is the canonical handle for a folder — always prefer it over rebuilding a location from `ref` when calling back in. ref: $ref: '#/components/schemas/synq.entities.v1.FolderRef' description: >- Structured, human-friendly address of this folder. Populated when it can be derived from the surrounding hierarchy (always for `GetFolderOf`, and for `Browse` when the parent location is known). When it cannot be derived, `folder_entity_id` remains the authoritative handle. name: type: string description: Display name of this folder (its own leaf name, e.g. "sales"). fullName: type: array items: type: string description: >- Full display path from the root down to this folder (root first, leaf last), e.g. ["clickhouse-prod", "default", "sales"]. Suitable for rendering a breadcrumb. type: $ref: '#/components/schemas/synq.entities.v1.EntityType' description: >- Entity type of this node. Folders synthesized purely for grouping report an unspecified type; container entities that also act as folders (databases, schemas, projects) report their real type. platform: $ref: '#/components/schemas/synq.platforms.v1.DataPlatformType' description: Platform this folder belongs to, when known. childFolderCount: type: integer description: >- Number of direct sub-folders. Best-effort: it may be reported as a collapsed count for lazily-loaded folders and can be 0 when the count was not loaded. memberCount: type: integer description: >- Number of direct, non-folder members (entities that sit directly in this folder). Best-effort and may be 0 when not loaded. role: $ref: '#/components/schemas/synq.entities.folders.v1.FolderRole' description: How this folder participates in browsing. title: Folder additionalProperties: false description: >- Folder is one node in the folder / containment hierarchy: an integration root, a container (database, schema, project), or a nested folder. Members that are not themselves folders (tables, models, …) are returned as entity ids, not as `Folder`s. synq.entities.v1.FolderRef: type: object properties: rootEntityId: type: string description: >- Opaque id of the entity the folder hierarchy hangs under — an integration root or container (for example a warehouse instance, a database, or a transformation project). Take it verbatim from `FolderRef.root_entity_id` of a folder you already read, or from an entity id returned elsewhere. folders: type: array items: type: string description: >- Ordered folder names from the root down to this folder (root first, leaf last), for example ["staging", "sales"]. Empty means the ref points at the root entity itself. Folder names are kept as separate segments (not joined with "/") because some platforms allow "/" inside a single folder name. title: FolderRef additionalProperties: false description: >- FolderRef is the human-friendly, structured address of a folder: the entity it hangs under (`root_entity_id`) plus the ordered folder names from that root down to the folder (`folders`). It is the stable way to name a folder across responses. Prefer it over the opaque folder entity id when you want to log, display, or reconstruct a location — the segments are the same names a user sees in the catalog, and they survive changes to the underlying id encoding. A `FolderRef` with an empty `folders` list names the root entity itself (a top-level integration or container the hierarchy hangs from). This type lives in `synq.entities.v1` (rather than a folder-specific package) so it can be shared by both the folders navigation API and the query API without an import cycle. synq.entities.v1.EntityType: type: string title: EntityType enum: - ENTITY_TYPE_UNSPECIFIED - ENTITY_TYPE_BQ_TABLE - ENTITY_TYPE_BQ_VIEW - ENTITY_TYPE_LOOKER_LOOK - ENTITY_TYPE_LOOKER_EXPLORE - ENTITY_TYPE_LOOKER_VIEW - ENTITY_TYPE_LOOKER_DASHBOARD - ENTITY_TYPE_DBT_MODEL - ENTITY_TYPE_DBT_TEST - ENTITY_TYPE_DBT_SOURCE - ENTITY_TYPE_DBT_PROJECT - ENTITY_TYPE_DBT_METRIC - ENTITY_TYPE_DBT_SNAPSHOT - ENTITY_TYPE_DBT_SEED - ENTITY_TYPE_DBT_ANALYSIS - ENTITY_TYPE_DBT_EXPOSURE - ENTITY_TYPE_DBT_GROUP - ENTITY_TYPE_DBT_SEMANTIC_MODEL - ENTITY_TYPE_DBT_CLOUD_PROJECT - ENTITY_TYPE_DBT_CLOUD_JOB - ENTITY_TYPE_SNOWFLAKE_TABLE - ENTITY_TYPE_SNOWFLAKE_VIEW - ENTITY_TYPE_SNOWFLAKE_STREAM - ENTITY_TYPE_SNOWFLAKE_DYNAMIC_TABLE - ENTITY_TYPE_SNOWFLAKE_TASK - ENTITY_TYPE_SNOWFLAKE_EXTERNAL_TABLE - ENTITY_TYPE_SNOWFLAKE_MATERIALIZED_VIEW - ENTITY_TYPE_SNOWFLAKE_PROCEDURE - ENTITY_TYPE_SNOWFLAKE_FUNCTION - ENTITY_TYPE_SNOWFLAKE_SEMANTIC_VIEW - ENTITY_TYPE_REDSHIFT_TABLE - ENTITY_TYPE_REDSHIFT_VIEW - ENTITY_TYPE_REDSHIFT_PROCEDURE - ENTITY_TYPE_REDSHIFT_FUNCTION - ENTITY_TYPE_TABLEAU_EMBEDDED - ENTITY_TYPE_TABLEAU_PUBLISHED - ENTITY_TYPE_TABLEAU_CUSTOM_SQL - ENTITY_TYPE_TABLEAU_TABLE - ENTITY_TYPE_TABLEAU_SHEET - ENTITY_TYPE_TABLEAU_DASHBOARD - ENTITY_TYPE_AIRFLOW_DAG - ENTITY_TYPE_AIRFLOW_TASK - ENTITY_TYPE_CLICKHOUSE_TABLE - ENTITY_TYPE_CLICKHOUSE_VIEW - ENTITY_TYPE_ANOMALY_MONITOR - ENTITY_TYPE_ANOMALY_MONITOR_SEGMENT - ENTITY_TYPE_SQLTEST_TEST - ENTITY_TYPE_RECON_SUITE - ENTITY_TYPE_RECON_CASE - ENTITY_TYPE_POSTGRES_TABLE - ENTITY_TYPE_POSTGRES_VIEW - ENTITY_TYPE_MYSQL_TABLE - ENTITY_TYPE_MYSQL_VIEW - ENTITY_TYPE_DATABRICKS_WAREHOUSE - ENTITY_TYPE_DATABRICKS_TABLE - ENTITY_TYPE_DATABRICKS_VIEW - ENTITY_TYPE_DATABRICKS_JOB - ENTITY_TYPE_DATABRICKS_JOB_TASK - ENTITY_TYPE_DATABRICKS_NOTEBOOK - ENTITY_TYPE_DATABRICKS_QUERY - ENTITY_TYPE_DATABRICKS_DASHBOARD - ENTITY_TYPE_SQLMESH_PROJECT - ENTITY_TYPE_SQLMESH_SQL_MODEL - ENTITY_TYPE_SQLMESH_PYTHON_MODEL - ENTITY_TYPE_SQLMESH_EXTERNAL - ENTITY_TYPE_SQLMESH_SEED - ENTITY_TYPE_SQLMESH_AUDIT - ENTITY_TYPE_SQLMESH_UNIT_TEST - ENTITY_TYPE_SQLMESH_ENVIRONMENT - ENTITY_TYPE_SQLMESH_SNAPSHOT - ENTITY_TYPE_DUCKDB_TABLE - ENTITY_TYPE_DUCKDB_VIEW - ENTITY_TYPE_TRINO_TABLE - ENTITY_TYPE_TRINO_VIEW - ENTITY_TYPE_ATLAN_ASSET - ENTITY_TYPE_ATLAN_INTEGRATION - ENTITY_TYPE_COALESCE_PROJECT - ENTITY_TYPE_COALESCE_ENVIRONMENT - ENTITY_TYPE_COALESCE_NODE - ENTITY_TYPE_COALESCE_NODE_TEST - ENTITY_TYPE_COALESCE_JOB - ENTITY_TYPE_CASTORDOC_TABLE - ENTITY_TYPE_CASTORDOC_DASHBOARD - ENTITY_TYPE_CASTORDOC_VIEW - ENTITY_TYPE_CASTORDOC_TILE - ENTITY_TYPE_CASTORDOC_VIZ_MODEL - ENTITY_TYPE_POWERBI_REPORT - ENTITY_TYPE_POWERBI_TILE - ENTITY_TYPE_POWERBI_DATASET - ENTITY_TYPE_POWERBI_DASHBOARD - ENTITY_TYPE_POWERBI_TENANT - ENTITY_TYPE_THOUGHTSPOT_LIVEBOARD - ENTITY_TYPE_THOUGHTSPOT_WORKSHEET - ENTITY_TYPE_SIGMA_WORKBOOK - ENTITY_TYPE_SIGMA_DATA_MODEL - ENTITY_TYPE_DOMO_PAGE - ENTITY_TYPE_DOMO_DATASET - ENTITY_TYPE_MSSQL_TABLE - ENTITY_TYPE_MSSQL_VIEW - ENTITY_TYPE_ORACLE_TABLE - ENTITY_TYPE_ORACLE_VIEW - ENTITY_TYPE_ATHENA_TABLE - ENTITY_TYPE_ATHENA_VIEW - ENTITY_TYPE_FABRIC_TABLE - ENTITY_TYPE_FABRIC_VIEW - ENTITY_TYPE_CUSTOM_ENTITY_GENERIC - ENTITY_TYPE_CUSTOM_ENTITY_CUSTOM_TYPE_MIN - ENTITY_TYPE_CUSTOM_ENTITY_CUSTOM_TYPE_MAX synq.platforms.v1.DataPlatformType: type: string title: DataPlatformType enum: - DATA_PLATFORM_TYPE_UNSPECIFIED - DATA_PLATFORM_TYPE_BIGQUERY - DATA_PLATFORM_TYPE_LOOKER - DATA_PLATFORM_TYPE_DBT - DATA_PLATFORM_TYPE_DBT_CLOUD - DATA_PLATFORM_TYPE_DBT_SELF_HOSTED - DATA_PLATFORM_TYPE_SNOWFLAKE - DATA_PLATFORM_TYPE_GCP - DATA_PLATFORM_TYPE_GIT - DATA_PLATFORM_TYPE_GITHUB - DATA_PLATFORM_TYPE_REDSHIFT - DATA_PLATFORM_TYPE_TABLEAU - DATA_PLATFORM_TYPE_AIRFLOW - DATA_PLATFORM_TYPE_CLICKHOUSE - DATA_PLATFORM_TYPE_POSTGRES - DATA_PLATFORM_TYPE_MYSQL - DATA_PLATFORM_TYPE_DATABRICKS - DATA_PLATFORM_TYPE_SQLMESH - DATA_PLATFORM_TYPE_DUCKDB - DATA_PLATFORM_TYPE_TRINO - DATA_PLATFORM_TYPE_ATLAN - DATA_PLATFORM_TYPE_COALESCE - DATA_PLATFORM_TYPE_CASTORDOC - DATA_PLATFORM_TYPE_POWERBI - DATA_PLATFORM_TYPE_THOUGHTSPOT - DATA_PLATFORM_TYPE_SIGMA - DATA_PLATFORM_TYPE_DOMO - DATA_PLATFORM_TYPE_MSSQL - DATA_PLATFORM_TYPE_ORACLE - DATA_PLATFORM_TYPE_ATHENA - DATA_PLATFORM_TYPE_FABRIC - DATA_PLATFORM_TYPE_SYNQ synq.entities.folders.v1.FolderRole: type: string title: FolderRole enum: - FOLDER_ROLE_UNSPECIFIED - FOLDER_ROLE_PRIMARY - FOLDER_ROLE_VISIBLE - FOLDER_ROLE_HIDDEN description: |- FolderRole describes how a folder placement participates in browsing. It mirrors the placement roles carried by the catalog. securitySchemes: bearerAuth: type: http scheme: bearer ````