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.
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
| Method | Path | Purpose | Reference |
|---|---|---|---|
GET | /api/v1/connectors | List connector metadata | listConnectors |
GET | /api/v1/connectors/{id} | Get one connector definition | getConnectorDetails |
POST | /api/v1/connectors/{id}/install | Install a connector | installConnector |
DELETE | /api/v1/connectors/{id}/uninstall | Uninstall a connector | uninstallConnector |
GET | /api/v1/connectors/{id}/health | Run a connector health check | getConnectorHealth |
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:
| Header | Use |
|---|---|
Authorization | Basic auth |
| Tenant (from Basic auth) | Tenant scope for install, uninstall, and health checks |
Content-Type | JSON 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.
Related Docs
Operational Readiness Checklist
Before relying on this page in a production rollout, pair it with the core operations docs:
- Deployment Mode Matrix for self-hosted, Evaluation, Enterprise, SaaS, and In-VPC fit
- Failure Modes And Recovery for degraded-provider, connector, approval, and runtime behavior
- Capacity Planning for sizing and growth signals
- Community vs Evaluation vs Enterprise for limits, support surfaces, and upgrade triggers