catalogType=iceberg-rest, serviceType=glue) with AWS SigV4 authentication. Data files must be Parquet.
Using Amazon S3 Tables instead? See Amazon S3 Tables: Onboarding via API. Using Nessie instead? See Nessie: Onboarding via API.
How it works
Onboarding is four calls. Each one feeds the next:All paths are relative to your controller base URL. The examples assume
export CONTROLLER=https://<your-controller>. On StarTree Cloud, the controller is reached through the data-plane proxy, so use export CONTROLLER=https://<data-plane-host>/api/pinot.If your controller requires authentication, add an Authorization header to every request — e.g. -H "Authorization: Bearer <token>". The examples below omit it for brevity.Prerequisites
- StarTree 0.15.0 or later with the External Table Beta feature enabled, and tiered storage configured on the cluster. Contact StarTree support if unsure.
- Network access to the controller REST endpoint, plus an
Authorizationtoken if your cluster requires auth. - AWS credentials (access key + secret key) with read access to the Glue catalog and the underlying S3 data.
- Your AWS account ID (the catalog warehouse) and the Glue database name.
Limitations
- Iceberg tables only. This path reads Glue’s Iceberg REST Catalog API — plain Hive/Parquet tables registered in Glue (non-Iceberg) aren’t reachable here. A separate native AWS Glue Data Catalog code path exists, but it can only browse databases/tables today, not complete onboarding.
- No assumed-role option for the catalog (REST) call itself — only for the S3 storage read. The call to Glue’s Iceberg REST endpoint always signs with a static AWS access key/secret; see Authentication.
catalog.iceberg-rest.auth.rest.servicemust be set toglueexplicitly or the SigV4 signature is computed for the wrong AWS service — see the Warning under Catalog (REST) authentication.
Authentication
An External Table authenticates in two places, configured independently so the catalog and the data can use different credentials:- Catalog (REST) — keys under
catalog.iceberg-rest.auth.rest.*. Calls to the Glue Iceberg REST endpoint always use AWS SigV4 with a static access key/secret — there’s no assumed-role option for this call today. (Assumed-role support below applies to the storage side only.) - Storage (S3 data files) — keys under
catalog.iceberg-rest.auth.storage.*. Choose any one of three methods.
s3:GetObject and s3:ListBucket on the source bucket/prefix, plus Glue read access (glue:GetDatabase, glue:GetTable, glue:GetPartitions) on the catalog. Verify S3 access from the cluster before onboarding:
Catalog (REST) authentication: AWS SigV4
The only supported method for the Glue Iceberg REST endpoint.authType is optional — it’s auto-detected as aws-sigv4 once accessKeyId/secretAccessKey/region are all present.
Storage authentication: choose one
Assumed IAM role (recommended for production)
No static secrets in the table config — every S3 read assumesroleArn via STS.
Cluster node role
Omit everyauth.storage.* credential key — only region is required. Credential resolution falls back to the AWS SDK default chain (the node’s instance profile / IRSA role), which must already have S3 access.
Static access keys
Quick tests, or when role-based access isn’t available. Accepts eitheraccessKeyId/secretAccessKey or the shorter accessKey/secretKey aliases.
Step 1: Validate and browse the connection
POST /connections/browse
There is no separate “validate” endpoint. Browsing the catalog is the validation step: a 200 with an items list (even an empty one) confirms your credentials and connectivity. Bad credentials, an unreachable host, or an unknown catalog type return an error.
- Set
pathto""to browse the root — this both validates the connection and lists Glue databases (namespaces). - Set
pathto a database name to list the tables inside it.
Request
Response
Step 2: Preview the schema
POST /tables/preview
Samples the source, infers a Pinot schema, and returns an enriched table config (S3 tier, raw field configs, time column) plus sample rows. Review it, tweak if needed, then carry the schema and config forward to steps 3 and 4.
The request and response share the same JSON shape. You send a
tableConfig describing the source; the response fills in schema, the enriched tableConfigs.offline, sampled rows, and a summary.Request
Top-level fields:config.inference — how the schema is derived:
Resolution order: explicit
schema → embedded schema → inferred schema.
config.sampling — how rows are sampled:
Setting the namespace and table. Take them from the browse response — set
catalog.iceberg-rest.table.namespace / .tableName to the NAMESPACE (Glue database) and TABLE you selected.Use executor: controller — it’s required for the controller-watcher flow and the observability endpoints. The input tableConfig is intentionally minimal; /tables/preview returns the complete tableConfigs.offline you persist in Step 4.Response
Adjust the schema (time column, column names, null handling) before moving on.
Step 3: Create the schema
POST /schemas
Send the schema object from the preview response. Rename its schemaName to match your table.
Step 4: Create the table
POST /tables
Send the enriched tableConfigs.offline object from the preview response. Its ExternalTableSyncTask block is what marks the table as external.
schedule (cron) interval. There is no separate start call.
Quickstart: onboard a table end-to-end
The whole flow as one script. Fill in the variables at the top, run the script, and the first sync starts automatically.0, verify it’s queryable.
Monitor onboarding
Three read-only endpoints report ingestion progress — run status, ingestion checkpoint, and source file count — and requireexecutor=controller (set automatically). See Observability for full request and response details.
Verify it’s queryable
Whenstatus is COMPLETED and segmentsUploaded matches filesDiscovered, run a query against the broker (or the Data Portal query console) to confirm the data is live:
summary.nSourceRows (preview only samples up to ~100 rows) — confirm it’s non-zero and plausible for your dataset. If status is COMPLETED but the count is 0, give segments a moment to load on the servers, then recheck; if it persists, see Troubleshooting.
What’s next
Now that the table is created and data is loading, these are the highest-impact follow-up steps:- Add indexes for your query patterns. Without indexes, every query scans all remote Parquet data. Add a range index on time/numeric columns, an inverted index on low-cardinality filter columns, and a bloom filter on high-cardinality ID columns. → Indexes
-
Enable caching and preload. Set
enable.prefetch.page.cache=trueandpreload.enable=trueon the S3 tier so index data is served from local disk on repeated queries instead of re-fetched from S3. → Data and Index Caching - Protect large-scan queries from OOM. For tables that receive heavy aggregations or wide scans, enable the query OOM killer so a runaway query is killed instead of crashing the server. → Best Practices & Configs — Query OOM protection
- Monitor ongoing syncs. Use the observability endpoints to check run status, ingestion checkpoint, and source file count after each scheduled sync. → Observability
For common questions and failures, see the FAQ and Troubleshooting.

