Does the API require WooCommerce consumer keys?

No for the Bridge public catalog-reading routes. They expose bounded public commercial data and do not grant administrative WooCommerce authority.

Can an agent update a product or create an order?

No. The Bridge catalog interface is read-only. Product administration and order operations remain outside its public contract.

Can an agent download the full catalog in one request?

No. Search and listing routes are paginated and bounded. Agents should narrow candidates first and request full detail only when needed.

Is this the same as a product feed?

No. A feed supports bulk submission or ingestion. The API supports live, selective requests against the merchant-controlled source.

Is this an MCP server?

No. It is the read-only commerce interface that agents and compatible integration layers can use. KaliCart provides a separate MCP surface for MCP clients.

What happens when the request limit is reached?

The store can return a rate-limit response with retry guidance. A compliant agent waits for the indicated interval before sending another request.

KaliCart Bridge · Technical solution

WooCommerce Product API for AI Agents

Expose a compact, read-only WooCommerce catalog interface for agent discovery, filtered search and selected-product verification—without publishing administrative REST credentials.

The direct answer

KaliCart Bridge publishes a public product-reading layer from the merchant’s domain. A compatible agent can discover the interface, search summaries with bounded pagination and request current detail for a selected product. The plugin reads public commercial facts from WooCommerce and keeps write operations outside the contract.

Why not give an agent the WooCommerce REST API?

The WooCommerce REST API is a broad application interface and commonly relies on credentials. A public shopping agent usually needs a smaller contract: discover the catalog, search economically, verify one offer and follow the canonical purchase URL. Reducing the available surface makes integration clearer and limits unnecessary data transfer and authority.

Request flow

1. Discover capabilities

The agent reads the store’s published discovery information to identify supported catalog routes and response guidance.

2. Search compact records

Text, category and pagination inputs narrow the candidate set. Results remain intentionally smaller than full product detail.

3. Verify one candidate

The selected product can be checked against current WooCommerce data for identity, price, availability, variants and purchase readiness.

4. Respect response signals

Structured errors, request ceilings and Retry-After tell an agent when a request is invalid, too broad or temporarily rate-limited.

5. Return to the canonical store path

The merchant’s product or checkout URL remains the authoritative place to select options, calculate destination-dependent totals and complete the purchase.

Data designed for product decisions

Signal	Why an agent needs it
Stable identity	Product ID, SKU and canonical URL help distinguish candidates and prevent accidental duplication.
Classification	Names, categories, brands and attributes support filtered discovery and comparison.
Offer facts	Current price, currency and stock state communicate what WooCommerce presently publishes.
Variant state	The response can indicate when a parent product still requires an exact option selection.
Media and detail	Images and richer product facts can be requested for the finalist instead of every search result.
Action boundary	Purchase readiness and canonical links show what is known and where the merchant must take over.

Built for bounded catalog access

Read-only public catalog surface; no order, customer or administration endpoints.
Pagination and maximum request sizes prevent a single query from demanding the entire catalog.
Compact search responses reduce token use, bandwidth and origin processing.
Rate-limit signals let a compliant agent wait and retry instead of hammering the store.
WooCommerce remains the live authority; cached or federated discovery can be rechecked at the merchant.

API, feed and MCP are different layers

Surface	Best use
Product feed	Bulk ingestion by a platform that defines a fixed catalog format and refresh process.
Bridge catalog API	Live, bounded discovery and product verification against the merchant’s domain.
MCP server	Tool discovery and invocation for MCP-compatible clients; it can use a catalog interface as its commercial data source.
WooCommerce checkout	Final option selection, shipping, taxes, payment and transaction authority.

KaliCart keeps these responsibilities explicit. The catalog API is not presented as an administrative MCP server, and a feed is not treated as proof of the final live offer.

Common questions

Does the API require WooCommerce consumer keys?: No for Bridge’s public catalog-reading routes. They expose bounded public commercial data and do not grant administrative WooCommerce authority.
Can an agent update a product or create an order?: No. The Bridge catalog interface is read-only. Product administration and order operations remain outside its public contract.
Can an agent download the full catalog in one request?: No. Search and listing routes are paginated and bounded. Agents should narrow candidates first and request full detail only when needed.
Is this the same as a product feed?: No. A feed supports bulk submission or ingestion. The API supports live, selective requests against the merchant-controlled source.
Is this an MCP server?: No. It is the read-only commerce interface that agents and compatible integration layers can use. KaliCart provides a separate MCP surface for MCP clients.
What happens when the request limit is reached?: The store can return a rate-limit response with retry guidance. A compliant agent waits for the indicated interval before sending another request.