Syncing and jobs

Trigger a feed sync from the CLI, watch it to completion, and inspect or cancel the sync jobs it produces.

3 min read

On this page

Trigger a sync
Sync a date range
Force past a running sync
Backfill flags
Watch a sync to completion
List jobs for a feed
Get a job, and re-watch it
Cancel a job
A common workflow
Next steps

A feed moves data from a bank to a destination. Every time it runs it produces a job you can track. The CLI lets you trigger a sync, follow it live, and review or cancel the jobs behind it.

Trigger a sync#

Start a sync for a feed by its id:

Shell

banksync feeds sync fed_123

By default this is fire-and-forget: the CLI creates the job and immediately prints it, so you can capture the job id and move on. It does not block.

ID         STATUS       TYPE           WRITTENjob_9f2a   ◐ created    transactions       0

Sync a date range#

Pass --from and --to (both YYYY-MM-DD) to sync a specific window:

Shell

banksync feeds sync fed_123 --from 2026-01-01 --to 2026-03-31

Force past a running sync#

If a sync is already running for the feed, a new trigger conflicts (exit code 5). Pass --force to cancel the in-flight run first, then start yours:

Shell

banksync feeds sync fed_123 --force

Backfill flags#

Two flags help with backfills and re-syncs:

--reset-cursors clears the feed's cursors and dedup state before fetching, for a full re-sync from scratch.
--skip-dedup bypasses the per-record dedup guard for this run, so previously seen records are re-emitted.

Shell

banksync feeds sync fed_123 --reset-cursors --skip-dedup

Watch a sync to completion#

Add --watch to poll the job until it reaches a terminal state, with live written-record progress on the spinner:

Shell

banksync feeds sync fed_123 --force --watch

⠹ Syncing feed fed_123: 318 written✓ Sync complete: 412 written

On success the final job is printed. On failure the CLI prints the job's error messages and exits nonzero, so a script can branch on it.

Watch is interactive only

--watch polls only where notices are allowed, meaning table output on a terminal. When output is piped, in a machine format, under --quiet, or in CI, the CLI prints the created job and exits 0 without polling. That keeps stdout deterministic for scripts. To follow a detached job later, use jobs get --watch below.

List jobs for a feed#

See a feed's recent jobs (most recent first), up to 20 by default:

Shell

banksync jobs list fed_123

Filter by status and cap the count:

Shell

banksync jobs list fed_123 --status failed --limit 5

Valid statuses are created, in_progress, paused, completed, failed, and cancelled.

Get a job, and re-watch it#

Fetch a single job by feed id and job id:

Shell

banksync jobs get fed_123 job_456

Add --watch to poll an already-running job to completion. This uses the same poller as feeds sync --watch, so you can detach from a sync and re-attach to the job later:

Shell

banksync jobs get fed_123 job_456 --watch

⠸ Job in_progress (207 written)✓ Job completed (412 written)

Cancel a job#

Cancel a created or in-progress job to release the feed lock:

Shell

banksync jobs cancel fed_123 job_456 --yes

On a terminal, the CLI asks for confirmation first. When prompts are not available (piped, CI, or --no-input) it refuses to cancel unless you pass --yes, so nothing is cancelled by accident. Cancelling a job that has already finished returns a conflict (exit code 5).

A common workflow#

Trigger a backfill, watch it, and inspect any failures:

Shell

# Kick off a full re-sync and follow it livebanksync feeds sync fed_123 --reset-cursors --watch
# Later, review the last few jobsbanksync jobs list fed_123 --limit 5
# Drill into a failed onebanksync jobs get fed_123 job_456 --json | jq '.data.errors'