> ## Documentation Index > Fetch the complete documentation index at: https://docs.quivr.thevibecompany.co/llms.txt > Use this file to discover all available pages before exploring further. # Answer a declared source challenge > Resolve a declared GET route with the same request limits and deadline as POST. Routes with auth: quivr_key require connector:push authorization and instance scope. Only synchronous provider challenges are supported; a GET answer carrying ingestion items is rejected before ingestion. Reads and management stay on the normal API. Plugin challenge (2xx) and refusal (4xx) replies carry the plugin's status, content type and body unchanged, marked with Quivr-Response-Origin: plugin. That header selects the plugin-defined response variant (x-quivr-plugin-response), including provider JSON or text challenges and statuses that overlap engine errors. Engine-generated failures have no Quivr-Response-Origin header and follow the JSON Error schema below. A bodyless challenge is relayed with parsed body null. Unknown paths return 404; undeclared methods return 405 with Allow. Authentication follows the declared auth mode: quivr_key or instance_token; credentials for one mode cannot authenticate the other. A 204 challenge must have an empty response body; a plugin answer combining 204 with a nonempty body returns 500 plugin_invalid_response. The same IP allowlist, token bucket, idempotency and audit rules as POST apply. Signature routes bypass the response cache so every admitted call reaches provider verification. Signature GET routes need no bearer key and bypass POST signature and replay checks; the provider challenge is still verified and answered by the plugin. ## OpenAPI ````yaml /openapi.yaml get /v0/connectors/{connector_id}/api/{path} openapi: 3.1.0 info: title: Quivr HTTP API version: 0.0.0-draft description: >- Every endpoint of the Quivr v0 HTTP API. Send an API key as a bearer token; the key decides the Organization, the actions and the Corpora a request may reach. servers: [] security: - ApiKey: [] paths: /v0/connectors/{connector_id}/api/{path}: parameters: - name: Idempotency-Key in: header required: false description: >- Optional opaque key of 1–256 bytes, scoped to the instance. Authorized requests replay the first completed plugin/ingestion answer within the deployment TTL for quivr_key and instance_token routes (default 24h), without calling the plugin or charging another rate token. Authentication, route/body validation, IP and rate refusals do not reserve keys. Reusing a key on another declared route still replays its original answer. schema: type: string minLength: 1 maxLength: 256 - name: connector_id in: path required: true schema: type: string - name: path in: path required: true description: >- The declared relative route path, including any nested segments and filled template values. schema: type: string maxLength: 8192 get: tags: - Connectors summary: Answer a declared source challenge description: >- Resolve a declared GET route with the same request limits and deadline as POST. Routes with auth: quivr_key require connector:push authorization and instance scope. Only synchronous provider challenges are supported; a GET answer carrying ingestion items is rejected before ingestion. Reads and management stay on the normal API. Plugin challenge (2xx) and refusal (4xx) replies carry the plugin's status, content type and body unchanged, marked with Quivr-Response-Origin: plugin. That header selects the plugin-defined response variant (x-quivr-plugin-response), including provider JSON or text challenges and statuses that overlap engine errors. Engine-generated failures have no Quivr-Response-Origin header and follow the JSON Error schema below. A bodyless challenge is relayed with parsed body null. Unknown paths return 404; undeclared methods return 405 with Allow. Authentication follows the declared auth mode: quivr_key or instance_token; credentials for one mode cannot authenticate the other. A 204 challenge must have an empty response body; a plugin answer combining 204 with a nonempty body returns 500 plugin_invalid_response. The same IP allowlist, token bucket, idempotency and audit rules as POST apply. Signature routes bypass the response cache so every admitted call reaches provider verification. Signature GET routes need no bearer key and bypass POST signature and replay checks; the provider challenge is still verified and answered by the plugin. operationId: challengeConnectorAPI responses: '200': description: The plugin's synchronous challenge answer. content: text/plain: schema: type: string headers: Quivr-Response-Origin: description: >- Present with value plugin only for a plugin-defined reply, whose status, content type and body are forwarded unchanged. schema: type: string enum: - plugin '429': description: >- Instance token bucket exhausted; no plugin call or idempotency reservation. headers: Retry-After: schema: type: integer minimum: 1 description: Seconds until the next rate token. content: application/json: schema: $ref: '#/components/schemas/Error' default: description: Structured engine error, or the plugin's refusal answer. content: application/json: schema: $ref: '#/components/schemas/Error' headers: Quivr-Response-Origin: description: >- Present with value plugin only for a plugin-defined reply, whose status, content type and body are forwarded unchanged. schema: type: string enum: - plugin security: - ApiKey: [] - InstanceToken: [] - {} components: schemas: Error: type: object additionalProperties: false properties: code: type: string minLength: 1 message: type: string minLength: 1 retryable: type: boolean field: type: string minLength: 1 description: >- JSON Pointer (RFC 6901) to the request member that caused a 422, when known (for example /config/url or /credential/secret/token on connector commands). resync_url: type: string format: uri-reference required: - code - message - retryable securitySchemes: ApiKey: type: http scheme: bearer description: >- API key, not necessarily a JWT. Server derives Organization, permitted actions and Corpus scope; every resource access is authorized. InstanceToken: type: http scheme: bearer description: >- Source-scoped token accepted only by its instance's declared instance_token routes. Never grants normal API or token management access. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.