Airbyte
Airbyte: inspect connections, sources and destinations, trigger and watch syncs, and read job history.
About
Airbyte ships in the w6w first-party pack. It declares 12 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
- App id
io.w6w.airbyte- Version
- 0.1.1
- Author
- w6w
- Licence
- MIT
- Categories
- Data Warehousing & ETL · DevOps & Infrastructure
Overview
Airbyte moves data between sources and destinations, and this app lets a workflow watch and drive that pipeline instead of running it from the Airbyte UI. Trigger a sync, cancel one that’s running, and read back job history with computed durations — including the “incomplete” status that a naive success/failure check would silently miss, meaning some streams landed and others didn’t.
Inspect the pipeline itself before acting: connections, sources, destinations and workspaces, including which connections are paused and which streams support incremental sync. Resetting a connection is kept as its own explicit action rather than a flag on a sync, since it clears the destination and re-reads the source from scratch — not something to trigger by accident.
A good fit for workflows that need visibility into pipeline health beyond “did it run” — catching syncs that finished without fully landing, watching for a connection Airbyte itself paused after repeated failures, and kicking off syncs on a schedule or a trigger rather than a timer inside Airbyte.
Build with Airbyte
Three routes to the same 12 actions. The Workflow tab is generated from Airbyte's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
Get a connection
connection-get One pipeline with its STREAM CONFIGURATION — the sync mode per stream, which decides whether a table is replaced, appended to, or deduplicated. Appending where you meant to deduplicate is how a table doubles every night.
List connections
connection-list The pipelines: source, destination and schedule. Separates INACTIVE connections — paused, or disabled by Airbyte after repeated failures — which are the commonest cause of 'the data is stale and nothing is broken', and MANUAL ones, which never run on their own.
Pause or resume a connection
connection-pause Stop a pipeline moving data, or start it again. Pausing KEEPS the configuration and the incremental state, so resuming picks up rather than re-reading. Note Airbyte also pauses connections on its own after repeated failures.
List destinations
destination-list Where the data lands — usually the expensive half, and usually shared by several connections, which makes a destination the blast radius of any change to it. The mapping back to pipelines is in `connection-list`.
Cancel a job
job-cancel Stop a running sync. Airbyte's verb is DELETE, but the job record survives as `cancelled` — what stops is the work. Airbyte writes as it goes, so a cancelled sync leaves the destination partly written, and the remedy is another sync rather than a rollback.
Get a job
job-get How one sync went — the half of a trigger that means anything. Returns FINISHED and SUCCEEDED as separate answers, because a job can be over and still be `incomplete`, which is a sync missing some of its streams.
List jobs
job-list Sync history, with INCOMPLETE counted separately from succeeded and failed — a workflow branching on `failed` treats an incomplete sync as a success, and an incomplete sync is a table missing rows. Computes each job's duration, which is what trends.
List sources
source-list Where the data comes from. Each source holds a credential to somebody else's system, so this list is also the inventory of what one compromise of Airbyte would reach — the secrets themselves come back masked.
Get stream properties
stream-properties-get What a source's streams are CAPABLE of, against a given destination — so 'make this incremental' can be answered before it is attempted. A stream syncs incrementally only if the connector exposes a cursor, and that is a fact about the connector.
Reset a connection
sync-reset DESTRUCTIVE. Clears the connection's data in the destination and wipes its incremental state, so the next sync re-reads everything from the source — which on a rate-limited source is days and on a metered one is a bill. One word apart from a normal sync.
Trigger a sync
sync-trigger Start a sync now — the point of driving Airbyte from a workflow rather than a schedule. It RETURNS IMMEDIATELY with a pending job, so nothing about the data is true yet. A sync already running is reported as a state, not thrown, because Airbyte refuses rather than queues.
List workspaces
workspace-list The containers connections live in, and the honest answer to what this application reaches — an Airbyte application carries the permissions of the user who created it, which is often every workspace in the organisation.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Airbyte's real ids.
{
"manifestVersion": "2",
"name": "airbyte-example",
"steps": [
{
"id": "connection-get",
"uses": {
"app": "io.w6w.airbyte",
"action": "connection-get",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"connectionId": "<connectionId>"
}
}
]
}Here are some of the things you can do
-
Get a connection
readconnection-get -
List connections
searchconnection-list -
Pause or resume a connection
performconnection-pause -
List destinations
searchdestination-list -
Get a job
readjob-get
+7 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Airbyte, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Airbyte. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "connection-get",
payload: {
connectionId: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value);npm install -g @w6w/cliw6w run conn_YOUR_CONNECTION_ID --action connection-get --payload '{"connectionId":"<value>"}'Give an AI agent Airbyte — without giving it Airbyte's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.airbyte#connection-get",
"input": {
"connectionId": "<connectionId>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Airbyte connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
What the agent gets
Credentials it can't read
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
A tool surface scoped to the caller
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
A durable workflow in one call
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Health-aware discovery
Airbyte's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Airbyte itself is MIT, and the runtime that executes it is source-available (FSL).
Health checks
Airbyte declares its own checks, so its health is a property of the app rather than something the host guesses at.
Airbyte Cloud status
Airbyte Cloud's status feed — INFORMATIONAL, because much of Airbyte is self-managed and this says nothing about those. It is also weak evidence generally: a stale pipeline is usually a paused connection or an expired source credential, not Airbyte being down.
Airbyte API reachable
Probes this connection's own Airbyte through the UNAUTHENTICATED `/v1/health`, which matters here because access tokens last three minutes — a signed check would report on the token. The response is PLAIN TEXT, not JSON.