Connectors overview
A connector is anything that reads your content, maps it to bAInquet's IngestItem shape, signs the request with the connector HMAC scheme, and POSTs it to the ingestion API.
Whatever method you pick, the job is identical: produce signed IngestItem requests against the same ingestion endpoints. bAInquet then extracts, normalizes, builds a knowledge graph, and publishes versioned node files to a CDN for AI consumers to read. The methods below are different ways to produce and sign those requests.
The catalog
bAInquet ships 13 prebuilt connectors, a reference SDK, the raw HTTP recipe (the generic API connector), the Universal AI Plugin for stacks with no connector, and an MCP server for the read side.
| Method | Type | Maps | Page |
|---|---|---|---|
| WordPress | PHP plugin | Posts, pages, WooCommerce products | WordPress |
| Shopify | Node standalone | Products, pages, blog articles | Shopify |
| Drupal | PHP module | Nodes, Commerce products, fields, taxonomy, media | Drupal |
| Magento | PHP module | Catalog products, CMS pages/blocks (per store view) | Magento |
| Joomla | PHP system plugin | com_content articles and categories | Joomla |
| Ghost | Node standalone | Posts, pages | Ghost |
| Laravel | Composer package | Any Eloquent model via a Mappable contract | Laravel |
| Symfony | Bundle | Doctrine entities via a mapper interface | Symfony |
| Next.js | npm package | Build-time content adapters plus an App-Router route | Next.js |
| Nuxt | Nuxt module | Nuxt Content plus pages, with Nitro server routes | Nuxt |
| Django | pip package | Any Django model via a registry plus signals | Django |
| Wix | Node standalone | Stores products, pages, blog, events, bookings | Wix |
| Webflow | Node standalone | CMS Collection Items via Webflow webhooks | Webflow |
| Connector SDK | TypeScript/JavaScript | The reference client plus signing primitives and a CLI | Connector SDK |
| Generic API | Raw HTTP, any language | The contract every other method targets | Generic API connector |
| Universal AI Plugin | AI agent recipe | Point an agent at any site; it self-configures | Universal AI Plugin |
| MCP server | Read side | Lets an AI client retrieve a published node | MCP server |
All 13 prebuilt connectors are implemented and proven by signer parity: each one's HMAC output is byte-identical to the canonical scheme, verified against the project-wide known-good vector, plus mapper unit tests. See Conformance for the full certification gate.
Not sure which one to use
The Choosing a method page is a decision table that maps your stack to the right connector.
The shared model
Every connector follows the same five-part shape.
- Signer. The HMAC scheme
bq.connector.hmac.v1is identical across all methods. PHP connectors reuse a shared signer built onhash_hkdf; Node connectors use the SDK or a vendored copy of it; Django uses a stdlib HKDF. See Ingestion and signing for the exact scheme. - Client. POSTs to the ingestion endpoints with retry, using the platform's native HTTP layer.
- Mapper. The only platform-specific part: it turns the platform's content model into
IngestItems. - Hooks and events. On content create, update, or delete, the connector ingests or tombstones automatically. This is the incremental sync path.
- Backfill. A command (
drush,bin/magento, a console script, the SDK CLI, ormanage.py) does the initial bulk import.
Push, not pull
bAInquet does not crawl your site. Connectors push content in: an IngestItem carries the canonical content plus a deterministic sha256: checksum, so an unchanged item produces an unchanged checksum and the server returns skipped without reprocessing.
Incremental and backfill
Two complementary paths keep a node current:
- Incremental sync fires on each content change (a CMS hook, an observer, or a webhook) and ingests or tombstones one item.
- Backfill is a bulk command that walks all published, access-granted content in chunks and batch-POSTs it. Run it once at install, and again to reconcile any missed webhooks.
Known issue: the delete endpoint
Connectors tombstone removed content by POSTing to POST /v1/ingest/delete. That server endpoint currently returns a 500 due to a known bug, so tombstones do not yet take effect; it is the one conformance case that fails today. Upserts and backfill are unaffected. See Conformance for the current status.
Prerequisites
Before any content can be ingested you need three things, common to every method.
- A verified website. Register your domain and complete ownership verification (DNS TXT, a
.well-knownfile, a meta tag, or plugin-signed). Only a verified site can ingest, or a site inside its grace window. The verification method sets the node's trust tier. - A connector token. Issue one from the dashboard for the verified website. The token has the form
connectorId.secretand is shown once at issue time. It is scoped to one website (the website id is also the HMAC salt) and to specific source types. Store it as a secret; rotate it if exposed. A connector token is ingest-only: it cannot publish. - The three request values every request carries:
| Value | What it is |
|---|---|
baseUrl | The bAInquet API origin: https://api.bainquet.online/v1 (locally http://localhost:8080). |
websiteId | The id of your verified website (the token is scoped to it, and it is the HMAC salt). |
siteDomain | Your verified domain, sent as X-Site-Domain. Every item's url host must equal it. |
TIP
See Connector tokens for issuing and rotating tokens, and Verifying ownership for the verification methods and trust tiers.
What you get back
Once ingested and normalized, bAInquet publishes versioned node files to a CDN: manifest.json (the pointer, flipped last and atomically), llms.txt, ai.json, entities.jsonl, facts.jsonl, relationships.jsonl, chunks.jsonl, qa.jsonl, sources.jsonl, schema.jsonld, sitemap-ai.xml, and trust.json. See Node files for the full output.
Related
- Ingestion and signing: the authoritative endpoint and signing reference.
- Envelope and errors: how to read every response.
- Node files: what your ingested content becomes.