Provider Authorization
Last updated: 21 September 2026 · Protocol kalicart-commerce-consent/1
A merchant running KaliCart Bridge may separately authorize KaliCart Global to deliver its public catalog onward to one named external product-discovery or agentic-commerce provider. This page is the technical reference: protocol, endpoints, and the current provider registry. For the plain-language merchant explanation, see the Bridge docs. For the legal text, see Terms of Use and Privacy Notice.
Three distinct mechanisms
Easy to conflate, kept structurally separate on purpose:
- Federated Catalog — a merchant's catalog becomes searchable inside KaliCart Global's own cross-merchant index. Global is the only reader.
- Provider authorization (this page) — a further, per-provider grant that lets Global re-deliver an already-federated catalog onward to one named external system. Requires Federated Catalog to be active first. Off by default; each provider needs its own explicit, revocable authorization — authorizing one never authorizes another.
- Direct merchant feed — a feed the merchant's own server generates and hosts. Entirely outside this federated path.
Protocol
kalicart-commerce-consent/1. The merchant's Bridge keeps a local, hash-chained, append-only ledger of grant/revoke actions and sends a minimal receipt to Global on each action. Global independently verifies every receipt against the merchant's live discovery document (commerce_distribution in the Bridge discovery JSON) before treating it as authorized — a plausible-looking receipt is not by itself a source of truth. Revocation is fail-safe: delivery is suspended immediately, before verification even completes.
A receipt never contains customer, order, payment or store-credential data — only the store URL, a consent identifier, provider/purpose identifiers, the grant or revocation action and timestamp, applicable terms version, the language shown to the merchant, and hashes of the canonical and localized authorization text.
Endpoints
| Method & path | Purpose |
|---|---|
GET /v1/bridge/provider-consent/providers | Public, keyless. The current provider registry — which providers exist, their purpose, terms version, and whether they are operationally enabled. |
POST /v1/bridge/provider-consent | Called by a merchant's Bridge to submit a grant or revocation receipt. Validates the payload, checks Federated Catalog eligibility for grants, stores the receipt, and schedules asynchronous verification against the merchant's live discovery document. |
GET /v1/bridge/provider-consent/status | Called by a merchant's Bridge (with domain and consent_id) to poll receipt and authorization status after submission. |
Current provider registry
| Provider | Purpose | Terms version | Status |
|---|---|---|---|
openai_acp | product_discovery | commerce-consent-1.0 | Not yet operationally enabled. Defined in the protocol and receiptable today; no catalog data is delivered to this provider until Global turns delivery on. |
The live registry is authoritative — fetch GET /v1/bridge/provider-consent/providers rather than relying on this page for current status.
Evidence
Every grant and revocation is retained as a minimal, receipted, tamper-evident record for as long as needed to operate the channel, document authorizations, resolve disputes, and establish, exercise or defend legal claims. See the Privacy Notice for retention detail.