Introduction

Siphon lets a vertical B2B SaaS add customer-facing integrations without adding a connector to its codebase. You describe a source API once — as a declarative connector spec — and Siphon handles the rest: authenticating, paginating, enriching, transforming, validating, and delivering the data on a durable, observable schedule.

The connector spec is the product. Everything else — the engine, the API, the admin UI, the embeddable widget — authors, executes, or observes a spec.

What you get

• A declarative spec. One YAML/JSON document describes auth, fetch + pagination, a dependent-call enrichment DAG, a JSONata transform, validation, and typed output columns. No per-connector code. See Connector Spec.
• A durable engine. Each sync is a crash-resumable workflow (Restate). A run pages through the source, enriches, transforms, validates, and delivers — every HTTP call logged (and redacted) for the Run Inspector. See Durable engine.
• Change-aware syncing. Push a watermark to APIs that support it, or fingerprint records client-side for APIs that don't — so an unchanged source costs almost nothing to poll. See Sync & change filtering.
• Bring-your-own destinations. Deliver to a customer's Postgres or SQL Server warehouse (two-stage, deduped, typed), or a webhook. See Destinations.
• Per-connection overrides. One base spec, adapted per customer — a different page size, extra output columns, a different mapping — without forking. See Connection overrides.

How the pieces fit

Siphon is a pnpm monorepo split into two planes:

• Control plane — the Next.js admin app + @siphon/api: spec authoring, connection lifecycle, runs, the inspector, quarantine, schedules, tokens, and outbound webhooks.
• Data plane — @siphon/engine, wrapped by @siphon/worker: resolve auth → fetch pages → enrich DAG → change-filter → transform → validate → deliver → advance the watermark, with Restate journaling each page.

Read Architecture for the full picture, or jump into the Quickstart.

Where to go next