Connector Configuration
Configure connector instances, transforms, secrets, and durable source checkpoints
After activation, configure each instance through the deployment's Configuration system. Each instance has independent versions that you can save, activate, or restore. The Connector Catalog lists plugin-specific fields.
Sink Configuration
| Setting | Description |
|---|---|
| enabled | Whether the connector instance is active |
| streams | Which Iggy streams and topics to consume from |
| schema | Message format - json, raw, text, proto, flat_buffer, or avro |
| batch_length | Number of messages to batch before sending |
| poll_interval | How often to poll for new messages |
| consumer_group | Optional consumer group for coordinated consumption |
| plugin_config | Plugin-specific settings (connection strings, credentials, table names, etc.) |
| transforms | Optional data transformations before sending |
Source Configuration
| Setting | Description |
|---|---|
| enabled | Whether the connector instance is active |
| streams | Which Iggy stream and topic to produce into |
| schema | Message format - json, raw, text, proto, flat_buffer, or avro |
| batch_length | Number of messages to batch before producing |
| linger_time | Maximum time to wait before flushing a batch |
| plugin_config | Plugin-specific settings (source connection, polling interval, etc.) |
| transforms | Optional data transformations before producing |
Runtime and Plugin Settings
Before upgrading the runtime, make sure that source destination topics use persisted durability. The runtime creates missing topics with that policy. It rejects existing destinations that use replicated.
Instance configuration separates pipeline fields, such as streams, enabled, and transforms, from plugin_config. Shared connectors configuration controls the runtime's Iggy connection, HTTP API, telemetry, logging, and checkpoint storage.
Instance fields also include plugin_config_format, verbose, and benchmark. Formats are json, yaml, toml, and text. Cloud configuration accepts plugin values according to the schema. The platform owns type, key, version, name, and the library path.
For Avro, set schema: "avro". Supply avro_schema_json or a schema file available on the runtime node. An inline schema avoids a file dependency on every node.
Source Checkpoints and Failover
A checkpoint records completed source progress. File checkpoints remain on the node's disk. HTTP checkpoints can survive node replacement if the service that stores them is shared and durable.
The runtime saves a checkpoint only after Iggy acknowledges its batch. If sending or checkpoint storage fails, the connector receives the batch again on its next poll. This repeats work instead of skipping it.
The HTTP source first queues webhook requests in memory. Its success response proves queue admission, not a durable Iggy write. Restart can lose queued requests, and sender retries can duplicate them. Use durable retries at the sender and include a delivery ID so downstream systems can remove duplicates.
HTTP checkpoint storage uses conditional writes with ETags, identifiers for stored versions, and an idempotency key for each logical save. A missing checkpoint returns 404. Other load failures must not restart ingestion from the beginning. Version conflicts or revoked authorization stop checkpoint writes until the connector restarts.
Checkpoint configuration requires administrative access. Use IGGY_CONNECTORS_STATE_STORAGE and the schema's IGGY_CONNECTORS_STATE_HTTP_* fields. Retrieving configuration over HTTP and storing checkpoints over HTTP are separate features.
Warden enables cluster sources only on the healthy local Iggy leader. Other nodes keep sources disabled while preserving the saved desired configuration. Leadership changes can still repeat work. Use durable checkpoints and downstream operations that are safe to repeat.
Data Transforms
Apply transforms in order to change message fields:
| Transform | Description |
|---|---|
add_fields | Add new fields to messages |
delete_fields | Remove fields from messages |
filter_fields | Keep only the listed fields |
update_fields | Modify existing field values |
proto_convert | Convert to or from Protocol Buffers |
flat_buffer_convert | Convert to or from FlatBuffers |
avro_convert | Convert to or from Avro using a schema |
unwrap_envelope | Unwrap a nested payload envelope into the top-level message |
To build a custom transform in Rust, implement Transform.
Examples
PostgreSQL Sink
{
"name": "orders-pg-sink",
"values": {
"enabled": true,
"streams": [
{
"stream": "orders",
"topics": ["completed", "refunded"],
"schema": "json",
"batch_length": 100,
"poll_interval": "1s",
"consumer_group": "pg-sink-orders"
}
],
"plugin_config": {
"connection_string": "postgres://user:pass@host:5432/orders",
"target_table": "order_events"
}
},
"activate": true
}Random Source (Development)
{
"name": "random-source",
"values": {
"enabled": true,
"streams": [
{
"stream": "test_stream",
"topic": "test_topic",
"schema": "json",
"batch_length": 1000,
"linger_time": "5ms"
}
],
"plugin_config": {
"interval": "3000ms",
"max_count": 1000000,
"messages_range": [1, 5],
"payload_size": 200
}
},
"activate": true
}Plugin Schema Validation
Each plugin schema defines types, defaults, and secrets. Creation and updates follow these rules:
- Unknown
plugin_configkeys are rejected. - Values must match their field types, such as string, integer, boolean, duration, or array.
- Fields marked
secret, such as passwords and connection strings, appear as***in API responses.
Before creating configuration, retrieve Get Config Schema for the available fields.
Configuration Flow
To configure an instance:
- Retrieve its schema for fields, defaults, and rules.
- Save values under the instance key to create a version.
- Activate that version, or use
"activate": trueduring creation.
Versions belong to individual instances. Changing one instance does not select a version for another.
Secret Masking
API responses show *** for secrets such as passwords, connection strings, and credentials. An update preserves masked values. Send only the fields that you want to change.
API Reference
A connector kind follows connector:{type}:{plugin_key}, for example connector:sink:postgres. Its configuration name is the activated instance key, such as orders-pg-sink. Use this name for activation and history. An arbitrary name does not create an instance.
Get Config Schema
Retrieve fields, types, defaults, and rules in the section format used by Iggy configuration:
curl {supervisor_url}/deployments/{deployment_id}/configs/connector:sink:postgres/schema \
-H "ld-api-key: YOUR_API_KEY"{
"sink": {
"name": "Sink",
"description": "Connector sink pipeline settings.",
"schema": []
},
"plugin_config": {
"name": "Plugin Config",
"description": "Connector plugin-specific settings.",
"schema": [
{
"key": "connection_string",
"name": "Connection String",
"description": "PostgreSQL connection string",
"default_value": "",
"kind": "string",
"editable": true,
"secret": true,
"requirements": [],
"rules": []
}
]
}
}The sink or source section contains pipeline fields, such as enabled state, streams, and batching. plugin_config contains plugin fields, such as connection strings and table names. Fields with "secret": true appear as *** in responses.
Create a Config
curl -X POST {supervisor_url}/deployments/{deployment_id}/configs/connector:sink:postgres \
-H "ld-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "orders-pg-sink",
"values": {
"enabled": true,
"streams": [
{
"stream": "orders",
"topics": ["completed", "refunded"],
"schema": "json",
"batch_length": 100,
"poll_interval": "1s",
"consumer_group": "pg-sink-orders"
}
],
"plugin_config": {
"connection_string": "postgres://user:pass@host:5432/orders",
"target_table": "order_events"
},
"transforms": {}
},
"activate": true
}'Supply these fields:
- Set
nameto the activated instance key. - Put schema-compatible configuration in
values. - Set
activatetotrueto select the new version as primary immediately.
A successful request returns 201 Created with the new configuration ID in ld-config. An existing name receives another version automatically.
Get Active Config
curl {supervisor_url}/deployments/{deployment_id}/configs/connector:sink:postgres/primary \
-H "ld-api-key: YOUR_API_KEY"{
"id": 1,
"kind": "connector:sink:postgres",
"name": "orders-pg-sink",
"primary": true,
"initialized": true,
"version": 2,
"created_at": "2026-03-16T12:00:00Z",
"updated_at": "2026-03-16T12:05:00Z",
"values": {
"enabled": true,
"streams": [],
"plugin_config": {
"connection_string": "***",
"target_table": "order_events"
},
"transforms": {}
}
}List Config Versions
curl {supervisor_url}/deployments/{deployment_id}/configs/connector:sink:postgres/orders-pg-sink/versions \
-H "ld-api-key: YOUR_API_KEY"Get a Specific Version
curl {supervisor_url}/deployments/{deployment_id}/configs/connector:sink:postgres/orders-pg-sink/versions/2 \
-H "ld-api-key: YOUR_API_KEY"Activate a Specific Version
Activation selects the primary version and starts reconfiguration on every node:
curl -X PUT {supervisor_url}/deployments/{deployment_id}/configs/connector:sink:postgres/orders-pg-sink/activate/2 \
-H "ld-api-key: YOUR_API_KEY"A successful request returns 204 No Content.
Delete a Config
curl -X DELETE {supervisor_url}/deployments/{deployment_id}/configs/connector:sink:postgres/{config_id} \
-H "ld-api-key: YOUR_API_KEY"Creation, activation, and deletion require deployment:config:manage. Reading configuration or schemas requires deployment:config:read.