Connect the systems you already run.
Govern everything that crosses.

A connection is something your product source declares, not an item you pick off a shelf. It says where the data lives, how it is read, and what Bijection is allowed to send back — and the platform holds it to exactly that.

See the systems

Data enters one way. You choose how it is read.

Everything captured from an external system crosses a single periodic boundary: the whole change is staged, applied in one transaction, and published as one version. A dataset declares which of four strategies reads it; the boundary behind them never changes.

Snapshot

Read the dataset in full on every run and let the boundary work out what changed. It is the default, and the one strategy every kind of connection supports.

Cursor

Follow one declared append-only column forward, so a run reads only the rows that arrived after the last accepted position.

Change data capture

Consume a database's own logical replication stream instead of re-reading the table, and publish the window it decoded as one new version.

Pushed stream

Accept authenticated microbatches pushed to Bijection, with partition, offset, event time and the lateness you tolerate declared in advance.

A capture publishes a complete set or nothing at all, so no reader ever sees half of one. Each published version records what was read, when the read started and finished, and the source position it was read from — or a plain record that the source could not offer one.

Copy it, or leave it where it is.

Some data belongs in the source plane, with history you can read back. Some should never be copied at all. A source declaration owns that choice, and the reads above it look the same either way.

Captured source

Rows are copied on a cadence into Bijection's own source plane.
Every governed read resolves one published version, so a result can be reproduced later.
History is kept at accepted capture boundaries, and a historical read names the version it wants.

Virtual table

Rows stay in the external system. Nothing is replicated.
Governed reads compile into the provider's own SQL and execute there, under the same policy as any other read.
The answer carries the source's consistency and the interval it covers. There is no local copy and no promise of historical replay.

Either way the connected system stays yours. It is a source, not a tenant: it never shares Bijection's database, its byte storage, or its source plane.

Writing back is an Action. Never a side effect.

No read can change a connected system. An outbound change is one declared operation on an Action, and it goes through the doorway a person goes through: plan what will change, review it where the rule requires, execute, record the fact.

A closed set of verbs

An HTTP operation is one of GET, POST, PUT, PATCH or DELETE with a declared body. Email is TLS SMTP with a fixed sender, one recipient and an immutable message. There is no general-purpose request escape hatch.

Credentials arrive last

The intent to call is recorded first and committed. Credentials are injected only as the request leaves, so they never enter the retained record of what was done.

The result is evidence, not a copy

A finished call records its status, a digest and the scalars the operation declared it would keep. Provider response bodies are not retained.

How Actions work

Authorise once. Keep the secret out of Git.

Installing a connector is one guided browser authorisation — offered as a page for people who want to be walked through it, and as a single command for people who do not.

The flow checks the identity it got back and the access it was actually granted before anything is stored. Only then are the client ID, the client secret and the durable credential written as immutable versions in your secret manager.

What lands in product source is a reference to those exact versions, reviewed like any other change. Secret bytes never enter Git, and there is no mutable credential store sitting behind the platform to drift out of step with it.

The ecosystem it addresses. Grouped by what these systems are.

These marks name the kinds of system a source declaration reaches: the stores, applications and channels an operation runs on, plus the providers a deployment can bind for inference. They are a picture of the ecosystem, not a fixed menu, and nothing here implies a partnership.

72 systems in 7 groups.

Databases and analytics

Relational and analytical stores. Captured on a schedule into the source plane, or left in place and read as virtual tables.

Object storage and files

Buckets and drives. A read is pinned to an object's version or generation wherever the provider exposes one.

Google Cloud Storage
Microsoft Azure
Google Drive
Dropbox
Box

Business applications

CRM, ERP, service desk, commerce, billing, signature and directory systems — where the records a process turns on already live.

Work and knowledge

Trackers, documents, sheets and bases — the places the work around a process is written down.

Engineering and telemetry

Repositories and the operational signals an engineering team already watches.

Communication and scheduling

Where a process reaches a person. Anything Bijection sends leaves through an Action, like every other change.

Model providers

Not captured as a source. A deployment binds its inference target to a provider, a requested model and a credential, so the model in use is a deployment decision rather than a prompt.

Product marks identify the corresponding products only. All trademarks and logos remain the property of their respective owners, and their inclusion here does not imply endorsement. Icons are used under the Devicon licence, Simple Icons (CC0 1.0) and Lobe Icons (MIT); full sources and licences are recorded alongside the assets.

Bring the systems.
We'll model the process.

Tell us which systems a process reads from, which one it has to change, and the rules that decide when. That scope is where an implementation starts.

Read the developer guide

Connect the systems you already run.Govern everything that crosses.