Hex integration

Last updated date:

How Seedling connects to Hex, which read-only information it uses, and how access and deletion are controlled.

1. Overview

The Hex integration reads authorized projects, collections, components, users, groups, runs, schedules, data-app metadata, and data-connection metadata through a workspace or personal API token.

Seedling strips connection secrets before staging data-connection records and treats queried-table observability as optional Enterprise enrichment.

2. Connection and scope

Seedling verifies the provider account before storing the connection. A personal connection remains actor-owned; a workspace connection is administered for the selected Seedling workspace. Credentials are never inferred from an email address or silently promoted between scopes.

Hex workspace or personal API token
Prefer an administrator-created workspace token. Personal tokens inherit the creating user's Hex access and expiration policy.
Connection ownership
Seedling supports actor-owned personal access and administrator-managed workspace access for this connector. The selected scope and exact connection remain fixed through synchronization, rotation, disconnect, and purge.

3. Hex data Seedling accesses

Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.

Projects
Projects, descriptions, owners, status, timestamps, sharing context, and supported components.
Workspace assets
Collections, users, groups, data connections with secrets removed, and project relationships.
Execution
Runs, schedules, status, timing, data-app metadata, and optional queried-table observability.

4. Read-only permission contract

Use read-only Hex token access for the released workspace assets.

  • Read projects — project metadata and supported components.
  • Read users and groups — attribution and sharing diagnostics.
  • Read collections — workspace organization and project relationships.
  • Read data connections — connection metadata with secrets redacted before staging.
  • Optional Enterprise observability — queried-table context only when separately available.
  • No project, collection, run, schedule, component, user, group, or data-connection mutation is exposed.

5. Security and access

  • Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
  • Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
  • The provider does not expose enough complete object-level audience evidence for Seedling to reproduce native permissions safely. Workspace content therefore uses the connection's restricted-by-default workspace-or-no-human-access policy; administrator and steward status grant no raw-content bypass.
  • For a personal connection, raw content remains visible only to the connecting member in human-facing Seedling surfaces. Personal content may contribute to trusted system exploration under workspace policy, but that authority never transfers to another member.
  • Generated output cannot bypass Seedling's human review, verification, and approval gates.

6. Retention and deletion

Connected data
Synchronized Hex records remain while the connection is active and are removed through a durable integration purge after disconnect.
Credentials
Stored Hex credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.
Backups
Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.