Skip to main content
Choose between an HTTP manifest and Go based on the system you are integrating. Use a manifest for a conventional REST or GraphQL source. Use Go for database protocols, change logs, custom behavior, and every sink.

​
Two paths

Adding a source usually means picking between these. A manifest. If the system is a REST or GraphQL API, you probably do not need Go at all. One generic HTTP connector interprets declarative YAML that declares endpoints, auth, pagination, field projection, incremental cursors, and parent and child relationships. Most SaaS sources ship this way, and adding another is a new manifest rather than a new codebase. See HTTP manifests. Go. Databases, replication logs, object stores, and anything needing real logic get a Go implementation. That is the path for every sink as well, since manifests describe reads only. See Writing a source and Writing a sink.

​
What the engine expects

Both paths produce a registered connector. Whatever you build declares a ConnectorSpec or SinkSpec describing its name, config schema, and what it can do, and the server drives everything from that declaration. The config form in the web app, the CLI flags, and validation are all generated from the schema you write, so a field declared once shows up everywhere without further work. Beyond a full read or basic write, capabilities are opt-in. Add only the interfaces required for discovery, recovery, incremental reads, CDC, schemas, or rate limits, and advertise only behavior the connector implements. See Optional interfaces for what each one unlocks.

​
Maturity

Registration includes a maturity level, which the API and web app show to users.
  • alpha is documentation-derived and not yet tested end to end
  • beta has run end to end, but is not verified across every supported object
  • stable is production-ready across everything it claims to support
Start at alpha. Move it up as coverage arrives.