Connect your data

A Connection is a configured link to one external system. Every connection carries a system type, and the set of system types is closed. There are seven, defined in Rust as the SystemType enum in crates/beetl-types/src/lib.rs. Adding support for a new system means adding a variant to that enum and a matching variant to ConnectionDetails next to it. There is no plugin registry, and no way to define a new system type from the UI or the API.

This page is the matrix. In the real build it is generated from the enum, so it cannot drift from the code.

The seven system types

Three of these pages are written. The other four are placeholders that exist so the shape of the section is visible. Write order follows what design partners actually use, not enum order.

Push and pull

Push types give you an endpoint and a bearer token. You POST to Beetl on your own schedule, and nothing of Beetl's runs inside your network. Webhook and HttpFeed work this way. File is push too, but through the browser rather than the API.

Pull types need beetl-connector running inside your network, because Beetl's cloud has no route to your database. The connector holds an outbound connection to Beetl, receives extraction jobs over it, runs the extraction locally, and pushes the resulting Parquet back through the same ingest API the push types use. PostgreSql, Microsoft365Bc and SapBusinessOne work this way.

ServerSentEvents sits between the two. The connector opens the stream and holds it, batches events into Parquet, and pushes batches on the feed path. It is listed as pull because the connector, not the source system, drives the connection.

Three words that get confused

Before your first connection

Ingestion fails until a tenant has a registered object store. With none registered, every ingest returns 422 OBJECT_STORE_NOT_CONFIGURED, whatever the source type. Registration lives under Settings and is TenantAdmin-only, so a first user without that role hits a dead end. See first run.

Supporting pages