Connect an engine

External data engines — Spark, Trino, DuckDB, PyIceberg, and any other Iceberg REST-compatible client — connect to the Scrydon catalog facade at:

https://<your-host>/api/table/iceberg

Step 1 — Mint an engine token

Engine tokens are organisation-scoped credentials a query engine uses to authenticate to the catalog. They carry an optional write flag; read-only tokens cannot perform POST, PUT, DELETE, or PATCH operations against the catalog. The organisation binding is set by the server from your session — you cannot mint a token for an organisation you are not a member of, and write tokens require organisation owner or admin.

From the UI (recommended)

You can mint and manage engine tokens without leaving the app:

• Per table — open any Iceberg table in Analytics and go to its Query tab. Toggle write access if needed, click Generate engine token, and the connection snippets below it are filled with your token, catalog URI, namespace, and table name automatically.
• Org-wide — go to Platform → Settings → Engine tokens (organisation owner/admin) to create, list, and revoke every engine token for the organisation in one place.

The token is shown once — copy it immediately and treat it like a password: it grants catalog-level access to your organisation's Iceberg tables.

From the API

An organisation admin can also mint a token directly against the platform engine-token endpoint:

curl -X POST "https://<your-scrydon-host>/api/auth/iceberg/engine-token" \
  -H "Authorization: Bearer <your-platform-session>" \
  -H "content-type: application/json" \
  -d '{"name":"spark-etl","organizationId":"<your-org-id>","canWrite":true}'
# → { "key": "...", "organizationId": "...", "canWrite": true }

Step 2 — Configure your engine

All engines authenticate using the Bearer token scheme (Authorization: Bearer <engine-token>) or the token configuration property below.

The catalog URI below is your Scrydon host's api-table base URL. In most deployments this is the same host you use for the rest of the API:

https://<your-host>/api/table/iceberg

For local development the default is http://localhost:7500/api/table/iceberg.

from pyiceberg.catalog.rest import RestCatalog

catalog = RestCatalog(
    "scrydon",
    uri="https://<your-host>/api/table/iceberg",
    token="YOUR_ENGINE_TOKEN",
)

# List namespaces
print(catalog.list_namespaces())

# Load a table
tbl = catalog.load_table("my_namespace.my_table")
df = tbl.scan().to_arrow()

What the catalog endpoint returns

On GET /api/table/iceberg/v1/config the facade returns your organisation's warehouse prefix. This is how Iceberg clients discover the correct warehouse without you needing to configure it manually. Most clients call this automatically.

Write access

An external-engine write passes two independent gates — both must allow it:

1. Engine-token write flag. The token must be minted with write access (canWrite: true). Read-only tokens receive 403 Forbidden on any POST, PUT, DELETE, or PATCH.
2. Per-table write policy. Each managed table carries a write policy that governs whether any external engine may commit to it — independent of the token. New tables default to Governed only, which rejects every external commit (even from a write-enabled token) so writes stay on the governed data plane.

Changing a table's write policy

Open the table in Analytics → Settings tab → External write access, then pick a Write policy:

Scrydon's internal StarRocks engine is the only engine that writes Parquet data files directly. External engine writes (via the REST catalog) write table metadata (schemas, snapshots, namespace entries) through the governed facade; the actual data-plane writes go directly to your object store via Lakekeeper-vended or remote-signed credentials.

How governance holds under federation

An external engine connects through two independent credential surfaces, and Scrydon governs each:

1. Catalog metadata (namespace / table / schema / snapshot listings) — authenticated by your engine token, organisation-scoped: a token never sees another org's tables (404 cross-org).
2. Data-plane bytes (the Parquet files) — vended or remote-signed per request by the facade, never handed out wholesale.

A raw external scan reads Parquet as stored, so per-column masks — which Scrydon applies as a read-time transform — are not baked into those bytes. Governance therefore holds a different way at each surface.

Reads — clearance-gated raw access (not per-column masks)

Before vending data-plane credentials for a table, the facade's raw-scan vending gate resolves the engine-token user's effective clearance. If any column's classification exceeds that clearance, raw-scan vending is denied — a user who could only see a column masked in the governed path cannot obtain raw credentials to read it unmasked. This is mandatory access control over discretionary sharing: it denies even org admins who lack the clearance.

• Need per-column masking applied to the data itself? Read through the governed data plane — the scrydon notebook SDK, the Analytics UI, or POST /data/v1/tables/:ref/query — which runs the masked-select kernel and returns masked cells plus a maskedColumns list.
• Direct-S3 engines (Snowflake external volume, Databricks STS) read bytes with their own cloud credentials, outside Scrydon's signer. Scrydon cannot mask or clearance-gate those reads — apply the engine's own row/column policies, and grant those integrations tokens only for tables whose sensitivity you accept sharing wholesale.

Writes — the per-table write policy

Every managed table carries a write policy (see Write access above): governed_only (default) rejects all external commits at the facade; open_append / open_full admit them and the platform reconciles the new snapshot after the fact (audit event, row-count refresh, governance re-stamp). A write-enabled engine token is still 403'd on a governed_only table.

Governance metadata travels with the table

Scrydon stamps governance onto the Iceberg table itself as properties — scrydon.classification, scrydon.write-policy, scrydon.identity-columns, scrydon.column-sensitivity — so any catalog-aware tool inspecting the table sees its data classification and identity columns without calling a Scrydon API.

Compatibility matrix

CI-verified engines are tested against Scrydon's REST facade on every pull request that touches the Iceberg surface (workflow test-iceberg-compat.yml). Community-verified engines have been validated manually but are not yet part of the automated matrix.

Catalog operations (namespace / table / schema / snapshot listing) are the always-verified contract for CI-tested engines. Data-plane reads depend on your storage backend (see footnote 1 below).

Writing in from a streaming engine

To stream or batch data into a managed table from Spark Structured Streaming, Flink, or the Kafka Connect Iceberg sink, see External write-in. It commits through this same catalog facade under an open_append write policy, and Scrydon reconciles the commits under governance after the fact.

Roadmap

Two capabilities are designed and gated on upstream engine support — they are not available yet:

• Interactive Arrow-speed reads (Arrow Flight SQL). A brokered StarRocks Arrow Flight SQL endpoint behind token auth with masked-query handles, so interactive reads reach engine-native Arrow throughput end to end without exposing raw governed SQL or StarRocks credentials. Gated on the Flight SQL endpoint being provisioned in the deployment.
• Iceberg format v3. Deletion vectors (faster merge-on-read) and row lineage (stronger commit-audit provenance). Gated on the compatibility matrix — both StarRocks and PyIceberg must read and write v3 before Scrydon writes any v3 table.

Rotating or revoking an engine token

Tokens can be revoked at any time from Platform → Settings → Engine tokens (organisation owner/admin). Revocation takes effect immediately; existing connections using the token will receive 401 Unauthorized on the next request.