Skip to main content
The Connector Builder describes an internal system as data, and Danube compiles it into a private, organization-scoped service whose tools behave like any other: searchable by your agents, credential-injected at call time, covered by policies and the audit log. Two kinds of connector exist.

HTTP connector

For an internal HTTP service with no published OpenAPI document. You describe the base URL, how it authenticates, and each endpoint you want exposed as a tool.

Flow

2

Infer or write the spec

If the service publishes an OpenAPI document, point the builder at the base URL and it proposes a spec. Otherwise list the endpoints to probe; the builder calls each one with your sample parameters and proposes parameters and output shapes from the responses. Nothing is stored at this step; you review and edit the proposal.
3

Validate and test

Validation checks the spec shape and reports the number of tools it will create. Test makes one real call to confirm reachability and authentication.
4

Dry run

The dry run executes each endpoint with sample parameters and reports pass, fail, or skip per check, including output-schema mismatches.
5

Create

The connector becomes a private service in your organization. Its tools are immediately callable by your agents.

Database connector

For read-only questions against Postgres or MySQL. Each query becomes a tool; parameters are typed and bound, never interpolated.
  • Danube never holds the connection string. connection_ref names an environment variable resolved where the query runs. With the data plane that is inside your network.
  • Read-only, enforced three ways. The SQL is validated as a single SELECT, the connection is opened read-only, and results are capped at 1,000 rows.
  • Introspection lists tables and columns so the builder can propose a starting set of queries.

Endpoints