> ## Documentation Index
> Fetch the complete documentation index at: https://filament.getgalaxy.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> How to add a connector, and which of the two paths to take

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](/pages/connectors/building-a-connector/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](/pages/connectors/building-a-connector/writing-a-source)
and [Writing a sink](/pages/connectors/building-a-connector/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](/pages/connectors/building-a-connector/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.