Pin it
Add the plugin toplugins in the QUIVR_CONFIG file of every api and
worker process, next to your other pins:
- Endpoint. A connector plugin receives credentials in its request bodies,
so its endpoint must use
https://. Plainhttp://is accepted only on a loopback address (127.0.0.1,::1,localhost). Plugin calls never follow redirects. - Kinds. Every kind the manifest declares under
contributions.connector.kindsbecomes available, beside the built-in kinds. Each kind has exactly one provider: startup refuses a kind that a built-in or another pinned plugin already provides (kind_conflict, or a message naming both providers). - Startup. The pin is validated without contacting the plugin: an invalid manifest or endpoint refuses startup, an unreachable plugin does not.
GET /v0/connector-kinds lists the plugin’s kinds with the config and
credential schemas from its manifest, so the web interface offers them
without changes. A kind that declares a credential schema needs a credential.
What the core does on each run
- At the start of a run whose credential was deposited after the last
successful poll, the worker asks the plugin to check the credential. A
refusal ends the run as
access_errorbefore any fetch. - The worker asks the plugin for pages from the Acquisition Checkpoint, at
most 10 per run. Each call is bounded by the manifest’s
timeout_ms, capped at 30 seconds. - Each answer is checked like the Contract Runner checks it. Its items go
through the ingestion path, with the Connector Instance as producer, and only
then does the checkpoint advance.
reads,diagnosticsandnoticefeed the usage counters and health as they do for a built-in kind. For an item not accepted yet, each attachment is described by the plugin, uploaded by it to a presigned PUT the core issues, and read back before the item is accepted (Plugin API 0.4). A run starts no new page after 2 minutes.
Push deliveries
A kind withmodes: [pull, push] also receives what the source sends. Set
public_url in QUIVR_CONFIG (for example https://quivr.example.com) and pin
the plugin on the api processes too. Each instance then has a public route,
<public_url>/v0/connector-webhooks/<connector_id> (its webhook_url), served
without an API key. The API relays each request to the plugin, which verifies
it with the credential. It ingests the items before answering the source, and
answers 503 with Retry-After when the plugin is down. Polling stays on as the
fallback, relaxed while the plugin reports push active; health.push shows
the push side. X lists use it: webhook mode.
Health
The operator guide for Connector Instances is Connector Instances.