Pulls the provider's documents for the caller's org and files them as knowledge…
Pulls the provider's documents for the caller's org and files them as knowledge sources, which the store's own hook then indexes — so a synced document is…
POST /v1/knowledge/connectors/{provider}/sync
| Address | https://api.hanzo.ai/v1/knowledge/connectors/{provider}/sync |
| Method | POST |
| Operation | post_knowledge_connectors_by_provider_sync |
| Auth | Authorization: Bearer $HANZO_API_KEY |
Pulls the provider's documents for the caller's org and files them as knowledge sources, which the store's own hook then indexes — so a synced document is retrievable exactly like a hand-written page. The org is the validated tenant and the credential is read from KMS, so an org can only ever sync its own connection. A provider failure is reported honestly (502) and recorded on the connector rather than silently swallowed.
Request
1 field.
| Field | In | Type | Required | Description |
|---|---|---|---|---|
provider | path | string | yes | Provider is the connector to act on: github, slack, google or notion. |
Response
| Status | Body | Meaning |
|---|---|---|
200 | kbSyncOut | ok |
200 body — 2 fields.
| Field | In | Type | Always | Description |
|---|---|---|---|---|
ingested | body | integer | — | Ingested is how many documents landed in the org's knowledge store. |
provider | body | string | — | Provider is the connector that was pulled. |
Failure carries the platform error shape — see Errors.
Examples
hanzo has no subcommand for this operation — the CLI serves only what cloud's live route table confirms. Use HTTP or an SDK.
import { Configuration, KnowledgeApi } from 'hanzoai';
const api = new KnowledgeApi(new Configuration({ accessToken: process.env.HANZO_API_KEY }));
const { data } = await api.postKnowledgeConnectorsByProviderSync({ provider: 'provider' });from hanzoai.cloud import ApiClient, Configuration
from hanzoai.cloud.api import KnowledgeApi
client = ApiClient(Configuration(access_token=os.environ["HANZO_API_KEY"]))
result = KnowledgeApi(client).post_knowledge_connectors_by_provider_sync(provider='provider')cfg := cloud.NewConfiguration()
cfg.AddDefaultHeader("Authorization", "Bearer "+os.Getenv("HANZO_API_KEY"))
client := cloud.NewAPIClient(cfg)
resp, _, err := client.KnowledgeAPI.PostKnowledgeConnectorsByProviderSync(context.Background()).Execute()
if err != nil {
return err
}use hanzo_cloud::apis::{configuration::Configuration, knowledge_api};
let mut cfg = Configuration::new();
cfg.bearer_access_token = std::env::var("HANZO_API_KEY").ok();
let result = knowledge_api::post_knowledge_connectors_by_provider_sync(&cfg, Default::default()).await?;import ai.hanzo.cloud.ApiClient;
import ai.hanzo.cloud.api.KnowledgeApi;
ApiClient client = new ApiClient();
client.setRequestInterceptor(b -> b.header("Authorization", "Bearer " + System.getenv("HANZO_API_KEY")));
var result = new KnowledgeApi(client).postKnowledgeConnectorsByProviderSync();The method above is the one at the current release of the document. [email protected] (npm) and [email protected] (PyPI) were generated from an earlier release, where this operation carried a different id, so it spells the method differently — regenerating the clients is what makes the two agree. SDKs →
curl -X POST https://api.hanzo.ai/v1/knowledge/connectors/<provider>/sync \
-H "Authorization: Bearer $HANZO_API_KEY"The door reaches knowledge through the knowledge tool, which names its 9 operations with its own verbs — this one among them, under a name only the door declares. describe explains any of them:
curl -X POST https://api.hanzo.ai/v1/mcp \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "describe",
"arguments": {
"op": "list_kb_connectors"
}
}
}'How is this guide?