Eduardo Ferreira
03/19/2026, 1:56 PMkapa.ai
03/19/2026, 1:56 PMairbyte_connector_configuration data source: [Terraform Registry]
data "airbyte_connector_configuration" "github" {
connector_name = "source-github"
connector_version = "2.0.0"
configuration = {
repositories = ["airbytehq/airbyte"]
credentials = {
option_title = "PAT Credentials"
personal_access_token = var.github_pat
}
}
}
resource "airbyte_source" "postgres" {
name = "Postgres"
definition_id = data.airbyte_connector_configuration.postgres.definition_id
workspace_id = var.workspace_id
configuration = data.airbyte_connector_configuration.postgres.configuration_json
}
When connector_version is omitted, the latest version is used automatically. This gives you explicit version control directly in your IaC configuration. [Terraform Registry]
Airbyte API
The API is the underlying layer that powers the Terraform provider. As of Airbyte 1.6+, the API also supports creating and updating custom connectors (YAML or Docker-based) via dedicated endpoints, e.g.: [release notes]
• POST /workspaces/{workspaceId}/definitions/declarative_sources/ — create a YAML source definition
• PUT /workspaces/{workspaceId}/definitions/declarative_sources/{definitionId} — update it
Recommendation
• Use Terraform if you want version-controlled, declarative management of your sources and destinations with explicit version pinning. It's the most automation-friendly approach for infrastructure teams. [Terraform docs]
• Use the API directly if you need more programmatic flexibility (e.g., scripting, CI/CD pipelines) or if you're managing custom connectors across workspaces. [release notes]
Both approaches support automation well; Terraform adds the benefit of state management and drift detection on top of the API. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Eduardo Ferreira
03/19/2026, 1:58 PMkapa.ai
03/19/2026, 1:58 PMimport block (Terraform v1.5.0+)
import {
to = airbyte_destination.my_airbyte_destination
id = "<destination-id>"
}
[airbyte_destination import]
Method 2: terraform import CLI command
terraform import airbyte_destination.my_airbyte_destination "<destination-id>"
[airbyte_destination import]
Both methods work for the generic airbyte_destination resource as well as typed resources like airbyte_destination_postgres, airbyte_destination_s3, airbyte_destination_bigquery, etc. [destination_postgres import; destination_s3 import]
-------------------------
Getting the Destination ID
The knowledge sources don't explicitly describe how to retrieve destination IDs, but the standard approaches are:
1. Airbyte UI: Navigate to the destination's settings page — the destination ID is typically visible in the browser URL (e.g., `.../destinations/`destination-id).
2. Airbyte API: Use the GET /destinations endpoint to list all destinations and find the relevant ID.
-------------------------
Note on airbyte_destination_definition
If you're importing a destination definition (rather than a destination connector instance), the import syntax is slightly different — it requires both an id and a workspace_id as a JSON-encoded string:
terraform import airbyte_destination_definition.my_airbyte_destination_definition '{"id": "...", "workspace_id": "..."}'
[destination_definition import] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.