Resolve products from your own HTML
New features
Turn the product page your user is viewing into a product object. The newPOST /v1/products/resolve-from-html endpoint accepts a product page’s HTML (up to 5 MiB) plus its URL, and returns the same response envelope as Product Lookup with a new source: "client_html" value. Octogen never fetches the page, never reads its index, and never stores what you send — extraction is the same deterministic JSON-LD → Open Graph → HTML meta pass the on-demand lookup path uses, applied to your bytes.Capture the live DOM from your client application while your user is on the product page (document.documentElement.outerHTML + location.href), relay it through your backend, and resolve exactly what the user saw — including storefronts that block server-side fetching entirely, and the precise variant and price state of the session. Live-DOM captures are already rendered, so storefronts that inject their JSON-LD client-side extract at full fidelity. For URLs on covered domains, Product Lookup remains the richer call.See the Resolve from HTML guide and API reference.Per-URL coverage view for URL Lists
New features
See exactly which of your URLs are covered. Every URL List’s BigQuery dataset now carries a second view,url_coverage_v1 — one row per URL in your list with (url, normalized_url, covered, exported_at) — so the uncovered portion of a list is a single query: SELECT url FROM url_coverage_v1 WHERE NOT covered.The view appears automatically in your linked dataset, including subscriptions created before it existed, and refreshes with the same daily export as products_current_v1, so the two views always describe the same snapshot. covered = TRUE means the products view has at least one row for that URL; matching tolerates the same variants as adds (query parameters, Shopify collection paths).No API or SDK changes. See the Coverage URL Lists guide.Coverage URL Lists
New features
Track Octogen’s coverage of your own product URL lists. The new Coverage API (/v1/coverage/url-lists) lets a Developer organization upload named sets of product URLs — up to 5 lists of 100,000 URLs each — that Octogen joins against every active crawled catalog daily. Each list is published as its own BigQuery Analytics Hub listing, and access is granted automatically to your organization’s registered BigQuery Readers, so subscribing works exactly like catalog listings. The shared view products_current_v1 holds the currently matched products with the same columns as catalog exports.URL mutations are idempotent set operations with per-URL outcomes: every URL is normalized server-side, unparseable entries are rejected individually with invalid_url without failing the batch, and matching tolerates common variants such as query-parameter differences and Shopify collection-path aliases.The Python and TypeScript SDKs expose all eight endpoints. See the Coverage URL Lists guide and API reference.Lookup URL fields clarified
Updates
Product Lookup responses now name each URL for what it is.POST /v1/products/lookup returns four URL fields with one meaning each: requestedUrl echoes the URL you submitted on every successful result; normalizedUrl (new) is the matched product’s Octogen-normalized stable URL on indexed results — submit it on a follow-up lookup to deterministically re-resolve the same product; resolvedUrl is the post-redirect URL on on-demand results; and canonicalUrl is reserved for the canonical URL the product page itself declares, on on-demand results only.Breaking change: canonicalUrl is now null on indexed results. If you stored it as the stable re-lookup URL, read normalizedUrl instead — it carries the same value indexed results previously exposed there.MCP: the lookup_product tool’s input parameter is renamed canonical_url → product_url; it accepts any real product page URL. Agents reading the tool schema at session start pick this up automatically; update any scripted caller that hardcodes the argument name.The Python and TypeScript SDKs expose the new normalizedUrl field. See the Product Lookup guide and API reference.On-demand Product Lookup
New features
Resolve product URLs beyond Octogen’s index. Product Lookup now checks the product index first and can fall back to bounded on-demand product resolution. Every success identifiessource: "indexed" | "on_demand"; on-demand results use the same partial-safe product view without fabricating a catalog, UUID, or lifecycle state.Use resolutionMode to keep the default auto behavior, require index_only, or request on_demand_only. Use onDemandCachePolicy to prefer a recent result or request a refresh. The Python and TypeScript SDKs expose the same optional controls.See the Product Lookup guide and API reference.Catalog access policy and product-only discovery APIs
Updates
Developers can search and browse every active crawled catalog. This policy automatically includes catalogs activated later and always excludes merchant catalogs. Catalog-specific BigQuery listing access remains separately managed by Octogen.Catalog enumeration has been retired for Developers. The RESTGET /v1/catalogs endpoint, MCP list_catalogs tool, SDK listing methods, and catalog summary response model are no longer available. Omit the optional catalog field to search all active crawled catalogs, or pass a known active crawled catalog key to scope a request.More Like This product search
New features
Find products similar to a source product.POST /v1/products/more-like-this accepts a product URL or UUID, derives a similarity query from Octogen product enrichment, excludes the source product, and returns the same paginated product list shape as search. Use it for related-product rails, substitutions, recommendations, and agent workflows that start from a known item.The TypeScript SDK exposes moreLikeThisProducts(...), and the Python SDK exposes more_like_this_products(...). See the More Like This guide and API reference.BigQuery catalog subscriptions
New features
Subscribe to catalogs in BigQuery. When Octogen shares catalogs over BigQuery Analytics Hub, the Python SDK can create linked datasets in your own Google Cloud project — so you can query full catalogs with SQL for bulk and analytical workloads. Thebigquery extra adds the subscribe_to_listing helper, an octogen-bq-subscribe CLI for one listing, and an octogen-bq-autosubscribe CLI for scheduled MCP-backed syncs as new listings become ready.All-catalog search
Update
Product search now supports all granted catalogs by default. Omitcatalog from POST /v1/products/search, search_products(...), or searchProducts(...) to search across every catalog your organization can access. Pass catalog only when you want to restrict results to one catalog.Week of May 18
New features
Developer MCP server is live. Connect any MCP-compatible AI agent — Claude Code, Claude Desktop, Codex CLI, and others — directly to your granted Octogen catalogs over OAuth 2.1 + PKCE. The initial product tools mirror the REST API:list_catalogs, lookup_product, and search_products. Tokens are scoped to your organization and refresh automatically until your sign-in session expires.See the MCP overview to choose a client and get started.Platform Catalog API v1 (REST) is generally available. Backends and batch jobs can now hit the same catalog data over HTTPS with an octo_live_... API key. Endpoints include GET /v1/catalogs, POST /v1/products/lookup, and POST /v1/products/search, with cursor-based pagination and facet support.See the API reference overview for endpoint details and the authentication guide for key setup.Updates
Codex CLI now uses a dedicated MCP endpoint. Codex CLI users should point their client athttps://codex-mcp.octogen.ai/mcp instead of the standard MCP base URL. The compatibility endpoint handles OAuth discovery in the format Codex expects, while issued tokens still target the canonical MCP audience — tools, response shapes, and catalog grants are unchanged.If you set up Codex CLI before this week, update your registration following the Codex CLI guide. All other clients continue to use https://mcp.octogen.ai/mcp.