Skip to main content
You will create four public API resources:
  • a reusable Kafka connection profile;
  • a Kafka source table;
  • an Iceberg sink table; and
  • a SQL pipeline that connects the tables.

Prerequisites

You need:
  • the base URL and bearer token for a running Ingest Engine deployment;
  • a Kafka cluster and a topic containing JSON events;
  • an Iceberg REST catalog; and
  • object storage accessible to the Iceberg catalog and Ingest Engine.
Set the Ingest Engine API values used by every request:
The example expects Kafka values with this shape:

1. Create the Kafka Connection Profile

Create a profile containing the settings shared by Kafka tables:
Save the id from the response:
bootstrap_servers is a comma-separated broker list. This example uses an unauthenticated Kafka listener. For SASL or AWS MSK IAM, replace the authentication object with the configuration described in the Kafka connector reference.

2. Create the Kafka Source Table

Create a source table for the clickstream topic:
Save the returned table id:
The table name becomes its SQL name. offset: earliest starts a new source at the oldest retained offset, while read_mode: read_committed excludes records from aborted Kafka transactions.

3. Create the Iceberg Sink Table

Iceberg configuration is supplied directly on the table; it does not use a connection profile. The following production payload uses a REST catalog, ambient object-store credentials, hourly partitioning, and explicit writer settings:
Save the returned table id:
The sink writes to analytics.clickstream and partitions records by the hour of event_time. If the REST catalog requires authentication, add its auth object as described in the Iceberg connector reference. Add only the storage options required by your object store and identity model.

4. Validate the SQL Query

Validate the query before creating the pipeline:
A valid query returns a graph and an empty errors array. Resolve every entry in errors before creating the pipeline.

5. Create the Pipeline

Create a production pipeline with four-way parallelism and a 10-second checkpoint interval:
Save the pipeline id from the response:
checkpointIntervalMicros is required for production pipelines. Iceberg publishes committed data during successful checkpoints, so newly processed records may not be visible until a checkpoint completes.

6. Monitor the Resources

Read the resources through their public API endpoints:
The pipeline response includes its compiled graph and current action fields. The jobs response reports execution state and failure details. The table responses show the resolved connector, schema, configuration, and consumer count.

Continue

Continue with HTTP to Iceberg for an API-driven pipeline that accepts events over HTTP.
Last modified on October 1, 2026