Connectors | Golden Reports Docs

A connector is the piece of the platform that knows how to talk to one kind of system - a relational database, a REST endpoint, a CSV file. The platform has one connector per supported kind of source; you pick which one to use when you register a data source.

For most users, connectors are invisible: you choose "PostgreSQL" from a dropdown when registering a data source and never think about them again. This page is for the people who do think about them - admins deciding which connectors to install, and anyone evaluating extensibility.

Connectors that ship by default

A standard deployment includes:

PostgreSQL

Covers most relational workloads, including PostgreSQL-compatible offerings such as Aurora Postgres, CockroachDB, and managed cloud Postgres. Push-down for filters, sorting, and pagination is fully supported, so most query work is done by the database itself.

REST API

For any JSON-over-HTTP endpoint. Configurable base URL, authentication (bearer, basic, custom header), and a "data path" to navigate into nested response bodies. Filtering and sorting push down as query-string parameters when the endpoint supports them; otherwise, the engine post-filters.

CSV

For file-shaped data. Accepts HTTP(S) URLs, S3-compatible URLs, and assets uploaded to the platform. Configurable delimiter, quoting, encoding, and header row. Useful for reference data, fixture datasets, and ad-hoc dumps.

Additional connectors (BigQuery, Snowflake, MongoDB, Stripe, Salesforce, and others) are delivered as Marketplace extensions or built in-house.

How connectors fit into the data flow

When a report runs:

The platform looks at the report's data context and gathers the data sources behind it.
For each data source, it builds a request for the appropriate connector.
The connector opens the connection (database, HTTP, S3), runs the fetch, and returns rows.
The platform applies any operations the connector couldn't push down - additional filters, sorting, aggregation, pagination.
The result populates your report.

That's how data gets into a report. A single GraphQL query may select fields that span several data sources; the engine fans out, fetches from each, and assembles one result.

Push-down vs post-processing

Each query carries hints (which filters, sorts, pagination the report wants) and operations (the platform's authoritative pipeline).

Hints are the connector's chance to be efficient. A database connector translates a filter hint into a WHERE clause; a CSV connector ignores it.
Operations run inside the platform regardless of what the connector did. So the result is correct whether the connector pushed down everything, some of it, or nothing.

This means a connector that knows nothing about SQL is still correct - just slower. The split is what lets the same data context work over a Postgres view and a CSV file without changing the report.

Tenancy and credentials

Connectors are isolated per tenant: two reports for two different tenants hitting the same physical source run as two independent fetches with two independent credentials. The platform never logs credentials.

Installing new connectors

There are two ways:

From the Marketplace. Workspace admins browse the Marketplace and install a connector. The platform pulls the signed bundle into the organization's plugin registry; the next report that needs it picks it up.
Side-load. Self-hosted deployments can drop connector bundles into the data provider's plugin directory and configure the registry to load them on startup.

For development of a new connector, see Data source connectors.

Set up real production data: Data sources.
Define the schema your reports query against: Data contexts.
Build a connector for a new kind of system: Data source connectors.