Skip to main content

Connector Marketplace API

Use the connector marketplace API to discover available connector types, inspect their config schemas, install tenant-scoped connector instances, and run health checks. This is one of the APIs that becomes more important as teams move from simple LLM chat apps into real multi-agent systems that need governed access to databases, APIs, caches, files, and business platforms.

Generated API reference

Full request bodies, response schemas, and status codes for every endpoint on this page are in the generated Orchestrator API reference, rendered from the published OpenAPI spec. Use the links in the table below to jump straight to an operation.

Endpoints

MethodPathPurposeReference
GET/api/v1/connectorsList connector metadatalistConnectors
GET/api/v1/connectors/{id}Get one connector definitiongetConnectorDetails
POST/api/v1/connectors/{id}/installInstall a connectorinstallConnector
DELETE/api/v1/connectors/{id}/uninstallUninstall a connectoruninstallConnector
GET/api/v1/connectors/{id}/healthRun a connector health checkgetConnectorHealth

Base URL:

http://localhost:8080

The Agent usually proxies these calls to the Orchestrator.

Marketplace IDs are build-dependent. In the current community and enterprise registries, installable IDs include amadeus-travel, redis-cache, http-rest, postgresql, and, in enterprise builds, slack and salesforce. Use GET /api/v1/connectors against the running deployment as the source of truth before calling an install route.

Authentication and Tenant Scope

Install and uninstall requests need tenant context. In database-backed deployments, tenant_id is required for connector install and uninstall lifecycle operations.

Common headers:

HeaderUse
AuthorizationBasic auth
Tenant (from Basic auth)Tenant scope for install, uninstall, and health checks
Content-TypeJSON body for installs

Discovery

GET /api/v1/connectors (listConnectors) is the safest way for engineering teams to see what the running build actually exposes — including each connector's config_schema, capabilities, and installed state — before trying to wire a complex agent workflow around databases, APIs, file stores, or SaaS systems.

Install and Uninstall

The path ID is the primary connector selector; the body carries the instance name, tenant_id (required in DB-backed installs), connector-specific options, and credentials.

Example:

curl -X POST http://localhost:8080/api/v1/connectors/postgresql/install \
-H "Content-Type: application/json" \
-H "Authorization: Basic $(echo -n 'client-id:client-secret' | base64)" \
-d '{
"name": "analytics-db",
"tenant_id": "tenant-123",
"options": {
"host": "analytics.internal",
"port": 5432,
"database": "analytics"
},
"credentials": {
"username": "analytics_user",
"password": "secret"
}
}'

DELETE /api/v1/connectors/{id}/uninstall (uninstallConnector) returns a similar success / message payload.

Health Checks

GET /api/v1/connectors/{id}/health (getConnectorHealth) returns the registry health result for that connector instance. This is the right endpoint for readiness checks before exposing a connector-backed tool to agents in LangGraph, CrewAI, or internal orchestrators.

Operational Readiness Checklist

Before relying on this page in a production rollout, pair it with the core operations docs: