Status and scope

This page is the map of what the platform does today. It is the canonical reference when another page is ambiguous about whether something works.

At a glance

Capability	Status
13 native connectors	Stable
Connector SDK (@bainquet/connector-sdk)	Stable
Ingestion API + HMAC signing	Stable
Universal AI Plugin	Stable
MCP server (read side)	Stable
Core node exporters (free)	Stable
Advanced exporters (all)	Stable (plan-gated)
Deterministic knowledge graph + merge policy	Stable
Atomic versioned publish	Stable
API keys (bnq_live_...)	Stable
Organization / website transfer	Stable
Webhook subscription management	Stable
Two-factor authentication (2FA)	Stable
Periodic job scheduler	Stable

Shipped Stable

Connectors

All 13 native connectors are implemented and HMAC parity-tested: WordPress (PHP plugin), Shopify (Node standalone), Drupal (module), Magento (module), Joomla (plugin), Ghost (Node standalone), Laravel (Composer package), Symfony (bundle), Next.js (npm package), Nuxt (Nuxt module), Wix (Node standalone), Webflow (Node standalone), and Django (pip package). The generic API connector is the raw HTTP + HMAC recipe, with the SDK as its reference implementation.

SDK

@bainquet/connector-sdk (v0.3.0) is dependency-free and exports the connector client (ingestBatch, ingestItem, delete, heartbeat, advertiseSchema), item helpers (makeItem, makeChecksum), and the signing primitives (signRequest, parseToken, deriveSigningKey, canonicalString, computeSignature, sha256Hex). It ships a bainquet-ingest CLI.

Ingestion API and HMAC signing

The connector-only ingestion surface is live: POST /v1/ingest/batch, /item, /delete, /heartbeat, and /schema. Requests are authenticated with a connector token plus the bq.connector.hmac.v1 signing scheme (HKDF-derived signing key, six-line canonical string, replay-guarded nonce). The HMAC verifier, replay guard, and SDK mirror are conformance-certified.

Universal AI Plugin

The plugin ships as an offline scaffold (bainquet-scaffold.md), an online bundle discovered at https://api.bainquet.online/.well-known/bainquet/manifest.json, and a Claude Skill (bainquet-pipeline).

MCP server

The read-side MCP server exposes one paid website's verified graph as read-only tools (search_website_knowledge, get_entity_facts, list_node_files) over stdio JSON-RPC. Every tool is tenant-scoped to a websiteId; plan gating (cap.mcp) is enforced upstream.

Node exporters

The free exporters always run with zero LLM and produce: manifest.json, ai.json, llms.txt, llms-full.txt, entities.jsonl, facts.jsonl (per language), relationships.jsonl, chunks.jsonl, qa.jsonl, sources.jsonl, schema.jsonld, and sitemap-ai.xml. The advanced exporters are also built and run when the plan-derived capability is present: trust.json, openapi.json, embeddings-manifest.json (gated on Q-11 embeddings), priority-feed.jsonl, changes.jsonl, versions.json, citations.jsonl, and mcp.json. See Node files.

Some advanced exporters carry documented limits that the publish pipeline tightens over time: versions.json lists the current version (the full persisted history and prior manifest checksums are backfilled by the publisher), and changes.jsonl reports file-level changes versus the previous version (record-level diffing is a planned refinement). The files are emitted and schema-valid today.

Authentication: 2FA

Two-factor authentication is implemented end to end: GET /v1/auth/2fa (status), POST /v1/auth/2fa/setup (begin TOTP enrollment, returns the secret + otpauth URI), /activate (verify a code, return one-time recovery codes), /disable, and /recovery-codes (regenerate). Login enforces the second factor (auth.mfa_required then TOTP or a single-use recovery code). TOTP is RFC 6238 with a one-step skew; recovery codes are hashed at rest and single-use.

API keys

Programmatic API keys are live: POST / GET /v1/organizations/{id}/api-keys and DELETE /v1/organizations/{id}/api-keys/{keyId}, guarded by organization_admin. The full key (bnq_live_*) is shown once and stored only as a hash; the auth middleware recognizes a bnq_live_* bearer token or X-Api-Key header and resolves an api_key principal.

Organization and website transfer

Organization ownership transfer is a pending-then-accept flow: POST /v1/organizations/{id}/transfer (owner initiates to a target email), POST /v1/organizations/transfers/{token}/accept (recipient accepts), and POST /v1/organizations/{id}/transfer/cancel. The reassignment runs as the org.transfer.execute job. Website transfer (POST /v1/websites/{id}/transfer) moves a website to another org the caller owns, synchronously.

Webhook subscription management

Per-website webhook subscriptions are managed via POST / GET /v1/websites/{id}/webhooks and PATCH / DELETE /v1/websites/{id}/webhooks/{webhookId} (organization_admin+). The signing secret is returned once on create and stored only as a hash. This is the management surface; outbound delivery is handled by the worker.

Periodic scheduler

The worker schedules repeatable maintenance jobs on configurable timers: analytics.aggregate (rollups), verification.check (ages out lapsed verification grace windows), and connector.heartbeat.check (flags connectors that stopped heart-beating). Each uses a stable repeat key so replicas do not stack the schedule. The verification sweep currently performs the time-based grace downgrade; an active DNS/well-known re-probe is a planned addition. The heartbeat sweep detects and reports stale connectors.

Publish pipeline

The atomic, versioned publish is real: immutable versions/{ulid}/ directories, a content-addressed cas/ dedupe store, and a latest/manifest.json pointer flipped last under a per-site Redis lock.

Notable spec drifts

These are places where the built server differs from the frozen spec text. The built behavior is what you get; reconciliation is tracked in the maintainer notes.

Area	Spec says	Server does
Item body cardinality	exactly one of html/text/json	at least one (the validator is an OR)
Publish (POST /websites/{id}/publish)	async, 202 + jobId	synchronous, 200 with versionUlid, versionLabel, files, cdnPath
Publish verification gate	409 website.not_verified pre-gate	not gated yet
Takedown (DELETE /websites/{id}/node)	202 per the REST spec	200 with { tombstoned: true } per the OpenAPI document

Related

• Changelog: the contract and documentation version history.
• Node files: the full file reference, with the planned set badged.
• Ingestion and signing: the live ingestion surface.