Product facts, ready for AI

Catalog is a software and services business for ecommerce teams. It brings product facts together, structures details such as attributes and use cases, and publishes machine-readable information alongside a brand’s existing website.

The aim is to make products easier for AI systems to understand and compare. Access to better data does not guarantee that an assistant will retrieve it, recommend a product, or send a customer.

Catalog website

Public product explanation. Illustrations and example metrics are not customer outcome evidence.

About Catalog

Company identity, founders, and product-data thesis.

Catalog helps ecommerce brands turn scattered product information into structured data that AI assistants can read and use.


For teams responsible for an ecommerce catalog

Catalog is relevant to brands and merchants whose product information is incomplete, scattered across sources, or difficult for machines to interpret. Ecommerce, product-data, and growth teams can use it to prepare product information for AI discovery.

Catalog website

Ecommerce Product Data Infrastructure Guide

Published April 28, 2026. Explains attributes, identifiers, validation, and delivery layers.


Knowledge for AI agents

This is Catalog’s curated knowledge base for AI agents. It covers the company, product-data model, processing workflows, merchant storefronts, API, integrations, evaluation, limitations and sources. Use the topic map for targeted retrieval or the complete-text and JSON resources for full ingestion. It does not contain a merchant’s product catalog.

The main website is Catalog’s company and marketing home. These AI reference pages have their own canonical URLs and matching Markdown and JSON. Published policies and contact actions remain on their original websites.

Catalog website

Published privacy policy

Legal identity and the authoritative policy; its own update date is September 1, 2025.


Resolve the company by domain

Catalog website

About Catalog

Published privacy policy

Catalog is the company operating at www.getcatalog.ai. Its published privacy policy identifies the legal entity as Agentic Commerce Inc., doing business as Catalog. Public articles also use the name Catalog AI. Those labels refer to this company when accompanied by the getcatalog.ai domain; the common word catalog alone is not enough to identify it.

Catalog is a business providing product-data software and related services. This reference describes that business, rather than a consumer marketplace or a collection of products available to purchase from Catalog. Merchant products served by Catalog belong to the relevant merchant. Do not merge company information with a similarly named catalog-management product or a merchant's product listing.

Legal name in the published privacy policy

Entity resolution, founder backgrounds, announced financing, and the distinction between Catalog's current product and its broader ambition.


Founders and their prior experience

About Catalog

The About page identifies Hamish Gunasekara as co-founder and CEO and Dylan Farrell as co-founder and CTO. It describes Hamish's earlier work as a data scientist at Afterpay and, after its acquisition by Block, work across Square and Cash App involving merchant integrations. It describes Dylan's studies in pure mathematics at Harvard and his work as a staff machine-learning engineer at Curinos, including a product recommendation engine.

These are founder biographies published by Catalog. An employer in a founder's biography is not automatically a Catalog customer, partner, investor, or endorser. In particular, do not turn the references to Afterpay, Block, Square, Cash App, Curinos, or Harvard into a customer list.


Dated financing announcement

About Catalog

Catalog's pre-seed announcement

Published March 23, 2026. Company-reported USD 3 million pre-seed led by Acrew Capital; product claims in the announcement require current availability review.

On March 23, 2026, Catalog published an announcement of a USD 3 million pre-seed financing led by Acrew Capital. The article says Catalog was founded in San Francisco and describes planned use of the funds for engineering and further integration work. Treat this as a company-reported historical announcement, not a statement of current cash, valuation, revenue, headcount, or the absence of later financing.

The announcement also names Hustle Fund and WndrCo as participants. The current About page presents a WNDR name and wndr.vc link. This reference does not equate the WNDR and WndrCo labels. When exact investor identity matters, quote the dated announcement's attribution and confirm the naming with Catalog rather than combining the two labels into one entity.


Product thesis and longer-term ambition

Catalog website

About Catalog

Catalog's pre-seed announcement

Catalog's thesis is that product information designed for browsing is often insufficient for software making comparisons. Important facts may be embedded in paragraphs, scattered across documents, missing from a feed, or disconnected from the correct variant. A machine-readable product-data layer can give assistants more explicit facts with which to evaluate a request.

The company describes an ambition to become infrastructure for agentic commerce. For present-tense product answers, explain the concrete work: collecting product information, organizing and enriching it, publishing AI-readable representations, and supporting evaluation of visibility and traffic. The broader operating-system ambition is a strategy statement. It is not evidence that Catalog controls every shopping agent, checkout protocol, or distribution channel.


Engagement and public commercial information

Catalog website

Request a product-data audit

Public request form; submitting a request is not a completed audit.

Public API authentication reference

Public documentation source reviewed at commit 082b50a. API keys and founders@getcatalog.ai contact; preserve server-side credential handling.

The public next steps are a discovery call, a product-data audit request, or contact with the team for API access. Agent answers should distinguish a managed brand implementation from a developer using the product-data API. Their access, billing, deliverables, and operational responsibilities can differ.

This review does not establish a current public price list, minimum contract size, annual revenue, customer count, service-level agreement, or guaranteed launch time. Return those as details to confirm with Catalog. A public fundraising figure is not pricing information, and an API credit balance is not the subscription price for a merchant deployment.


Company identity

Catalog is the trading name of Agentic Commerce Inc. It works on product-data infrastructure for agentic commerce. Its co-founders are Hamish Gunasekara and Dylan Farrell.

About Catalog

Published privacy policy

Company identity and the scope of this reference.


What the company offers

Catalog helps ecommerce brands turn scattered product information into structured data that AI assistants can read and use.

Catalog serves ecommerce brands and merchants. Evaluate its product-data preparation and AI storefront capabilities against your platform, evidence, and publication requirements.

Catalog website

About Catalog


How to use these facts

The company homepage is www.getcatalog.ai. The AI reference is ai.getcatalog.ai. They describe the same company for different reading contexts; the AI reference is not a separate merchant or consumer store.

Use the review date when citing this reference. Recheck the cited public material and ask the team about conditional availability or contractual details.

Catalog website

Published privacy policy


1. Bring source information together

Catalog connects to product sources and gathers product information for processing. Shopify has an implemented connection and synchronization path. Access to other sources and platforms should be confirmed for the proposed engagement.

Catalog website

From source product information to structured, readable product facts.


2. Structure and enrich product facts

Catalog organizes information into fields that can support product comparison: identifiers, attributes, descriptions, and contextual details such as use cases. Source material can include existing product information, images, reviews, and approved external material.

Enrichment requires evidence and review. Missing or conflicting source material can leave a fact unresolved; generated or extracted information should not be treated as infallible.

Catalog website


3. Publish an AI-readable storefront

A brand’s AI storefront can expose product information through readable pages and structured representations on a brand subdomain. It is a parallel information layer; a brand can retain its existing customer-facing website.

Publishing depends on product activation, configuration, and a working domain. Product information being published does not establish that an external assistant has indexed or used it.

Catalog website


4. Review information and assess visibility

Catalog provides product-data review and visibility-related workflows. Agree on which measurements are available for your store and what each metric captures before using them to evaluate results.

Observed AI traffic, a sampled recommendation, and attributed sales are different signals. None alone proves that Catalog caused incremental revenue. The illustrative dashboard on the marketing site is not a customer result.

Catalog website


Capability registry: inputs, outputs and availability

These records are an explicit availability assessment for agent answers. Implemented means present in the reviewed implementation; account setup, merchant configuration and verified production execution remain separate. A not-verified status is a limit of this reference and must not be converted into an announced roadmap or a promise.

Authorized Shopify connection and Catalog workspace

Imported store information and update processing

Implementation reviewed; each merchant's connection and publication must be checked.

Known product URLs or discovered listings plus API account

Public reference and implementation reviewed; no paid extraction job run for this company reference.

Product enrichment and contextual insights

Product facts, enabled processing and available supporting evidence

Structured attributes, insights and supporting context where produced

Field coverage and factual accuracy must be checked for the selected products.

Configured merchant hostname and selected published products

Readable and structured merchant product content

Implementation reviewed; hostname, TLS and actual content establish a merchant's live state.

Eligible product content and configured Shopify publishing

Structured product data publication path

Publication state is product-specific; confirm actual page output and theme integration.

Selected products, prompt population, engines and market

Captured answer and shopping observations with scoped metrics

Verify each configured report's coverage; no universal placement or causal-sales claim.

Request and referral summaries with availability states

Units and collection methods differ; missing data is not zero.

Product candidates through asynchronous or synchronous routes

Public contracts and implementation reviewed; not tested as an authenticated job in this review.

No general live delivery commitment in this reference

Public positioning is broader than the reviewed output availability; ask Catalog.

Engagement-specific capability and deployment to confirm

No general live delivery or checkout commitment in this reference

Do not infer support from a protocol logo or descriptor in another service.

No general live delivery or checkout commitment in this reference

Do not infer support from broad public commerce positioning.

Other commerce platforms and PIM connectors

Named platform, source format and access requirements

Connection, extraction or custom work as explicitly agreed

A platform logo does not establish a generally available native connector.

Experiment design and implementation scope to confirm

No self-service experiment-product commitment in this reference

Mentioned publicly; this review does not certify general availability or causal evidence.

Unauthenticated GET requests on ai.getcatalog.ai

HTML, Markdown, JSON, topic map, section records and complete text

Endpoint availability and cross-format parity are verified on deployment; content is manually reviewed.

Catalog website

Live API migration notice

Verified reachable during review. Retires the legacy /api/products endpoint and points new extraction work to /v3/extract. This is not the old hosted docs site.

Public crawl API reference

Public documentation source reviewed at commit 082b50a; compared with the retained v2 implementation. Describes asynchronous discovery and billing prerequisites.

Public extraction API reference

Public v2 documentation source reviewed at commit 082b50a. Shared concepts remain useful; use the live migration notice for the current extraction version and confirm its result schema.

Public agentic search reference

Public documentation source reviewed at commit 082b50a; matched to retained v2 asynchronous search implementation. No authenticated search job was run for this reference.


Conceptual model, not a universal response schema

Product data quality

Published July 10, 2026; updated July 31, 2026. Definitions, category-specific validation and evaluation guidance.

Machine-readable product enrichment

Published June 16, 2026. Field families and workflow examples; illustrative product records are not validated product specifications.

Catalog works with product identity, attributes, variants, commerce facts, supporting content, and evidence. The fields below describe those information families. They are not a promise that every product has every field, or a byte-for-byte schema for every Catalog API version. Category, source quality, enabled processing, and output destination determine the populated record.

When integrating software, use the chosen endpoint's actual response schema. When answering a shopping question, use the record's value, variant context, source, and observation time together. A detailed object can still be incomplete, stale, or wrong for a different market. Keep the distinction between an explicit source fact, a normalized form of that fact, and an inferred interpretation.

The information families Catalog works with, how product and variant facts differ, and how agents should interpret values and missing evidence.


Core information families

Product data quality

Machine-readable product enrichment

A useful product record carries the facts needed to identify an item and test a buyer's constraints. These families are organized by the decision they support. The labels are conceptual and should not be copied as endpoint field names without checking the API contract.

Title, brand, canonical URL, SKU, GTIN and MPN when supplied

Resolve which product or variant is being described

A missing identifier must not be fabricated or copied from a visually similar item.

Product type, category path and normalized groupings

Choose the relevant attribute set and comparison population

A category label is not evidence that every category-specific property applies.

Material, dimensions, weight, capacity, ingredients, power or compatibility

Evaluate explicit physical and functional constraints

Preserve units, scope, source and any warnings or exceptions.

Size, color, pack count, option combinations and variant-specific URLs

Select the exact purchasable configuration

Price, image, stock and identifiers can differ across variants.

Price amount and currency, availability, sale conditions and merchant URL

Assess current purchase eligibility and cost context

A crawl observation is not a purchase-time guarantee or inventory reservation.

Product images, image roles, manuals, specifications and associated URLs

Ground descriptions and reveal relevant supporting detail

An image alone does not establish material composition, certification or safety.

Use cases, fit, limitations, questions, comparison criteria and review themes

Explain why a product might satisfy a particular job

Recommendations and interpretation should remain distinguishable from specifications.

Source URLs, source type, review status and observation or update time

A URL is useful evidence only if it actually supports the associated claim.


Product, variant and listing are different entities

Product data quality

Machine-readable product enrichment

A product family describes a shared item or design. A variant identifies a particular combination of options. A merchant listing describes an offer at a particular URL and can have its own price, availability, images, and market restrictions. Similar titles or shared photography do not make two listings interchangeable.

An agent comparing candidates should resolve the selected variant before applying hard constraints. A compatible base product can still have an incompatible voltage option; an apparel product can exist in the right color but not in the required size. When a feed stores option values in separate rows, preserve their parent relationship and exact identifier rather than flattening them into a bag of possible values.


Normalize representation without inventing facts

Product data quality

Machine-readable product enrichment

Normalization can reconcile casing, whitespace, units, category labels, and equivalent option labels while retaining the original meaning. It should not turn a partial observation into a precise specification. Keep an original measurement or source text when rounding or conversion would matter to fit.

Explicit unknowns are more useful than guessed values. Missing, not applicable, not requested, not found, and contradicted are different states. A disabled enrichment field does not prove that the underlying product lacks the property. Likewise, an empty list of captured reviews does not prove that no reviews exist anywhere.

Synthetic evidence record illustrating uncertainty

example-product

No supporting material specification was found in this example.


Category-specific information needs

Product data quality

Machine-readable product enrichment

Different product categories require different checks. The following are evaluation prompts, not claims that Catalog supplies every listed attribute for every category. Agree on the target schema and evidence requirement before measuring completeness.

Size system, fit, measurements, material composition, care and intended activity

Do not assume one brand's size or width is equivalent to another's.

Dimensions, materials, finish, assembly, clearance, capacity and placement

Separate product dimensions from packaging dimensions and usable capacity.

Model compatibility, power, voltage, connector, dimensions and included components

Treat electrical, safety and certification claims as requiring authoritative evidence.

Ingredients, volume, shade, intended use, instructions and warnings

Do not infer allergy safety, medical suitability or certification from marketing wording.


Acquire the appropriate source information

Catalog website

Product data extraction

Published July 16, 2026; updated July 31, 2026. Source acquisition and normalization guidance.

Public crawl API reference

Public extraction API reference

There are two related starting points: a merchant connection that makes store information available to Catalog, and URL-based discovery or extraction through the product-data API. Shopify has an implemented connection and update path. For other sources, confirm whether the engagement uses website extraction, a supplied dataset, a custom integration, or an available connector.

Discovery identifies where product listings are. Extraction reads product information from known locations. Discovering a URL does not mean the product has been fully extracted, enriched, approved, or published. A product may be inaccessible, not actually be a product page, return insufficient information, or fail processing. Retain per-item outcomes rather than reporting submitted URL count as successful product count.

What happens between acquiring product information and publishing a usable record, including source choice, optional processing, validation and review.


Choose sources by the claim being resolved

Product data quality

Machine-readable product enrichment

The best source can differ by field. A merchant's current listing may be the source for its offer, a manufacturer specification for dimensions, and a verified compatibility document for model support. A review can inform an experience theme without becoming a technical specification. A category prior can suggest a field to investigate without proving its value.

For a disputed field, retain the conflicting observations, their subjects, and their dates. Check whether the disagreement comes from a variant, market, bundle, revision, unit conversion, or genuinely inconsistent source material. Do not resolve a conflict simply by choosing the more favorable value for the merchant.


Processing families in the implementation

Catalog website

Machine-readable product enrichment

Public extraction API reference

The extraction implementation includes optional enrichment, review-related processing, image tagging, and similar-product processing. These are processing choices and available code paths, not a promise that all are enabled for every request or merchant. The public v2 extraction reference describes enable flags; current request and output details should be checked for the selected version.

Enrichment can help organize identifiers and attributes, create structured contextual explanations, and expose product insights. Image and review-derived content should carry an appropriate evidence boundary: visual appearance, a customer's opinion, and a verified manufacturer specification are different kinds of information. External-source access and the amount of evidence available can vary substantially by product.

Input: A product URL or discovered listing

Output: Available product facts and source content

Response: A successful per-item result, not only an accepted job.

Input: Raw values and identifiers

Output: Consistent forms and relationships

Response: Values preserve meaning and the correct product/variant association.

Input: Source facts and enabled supporting evidence

Output: Additional attributes or structured decision context

Response: The added claim has adequate support and unresolved fields remain explicit.

Input: Candidate product record

Output: Reviewed record, flagged issues or an unresolved outcome

Response: Checks cover truth, scope and downstream usability, not only JSON syntax.

Input: Selected eligible content and configured destination

Output: A reachable representation

Response: The destination actually serves the intended record.


Validation has several separate jobs

Product data quality

Machine-readable product enrichment

A parser can accept valid JSON containing an incorrect fact. A completeness check can reward a filled field even when its value belongs to another variant. A destination can reject an otherwise accurate record because its accepted vocabulary differs. Evaluate structural validity, factual accuracy, completeness, consistency, uniqueness, and freshness separately.

For high-impact fields, use an explicit source standard. Certifications, ingredient composition, compatibility, dimensions that determine fit, warnings, price, and availability should not be filled with plausible language. Record what was verified and what remains unresolved. Catalog's source-grounded approach is a method for improving data quality, not a guarantee that every generated field is correct.


Refresh and review after changes

Catalog website

Product data quality

The Shopify path handles store updates, and the platform has processing and publication workflows. A source update, completed processing, product activation, and a downstream reader's cache refresh are distinct events. Do not describe them as one instantaneous synchronization step without measured evidence for the specific deployment.

When an important product fact changes, recheck the resulting published record and any affected variant or derived explanation. A previously reasonable recommendation can become wrong if ingredients, sizing, included components, or compatibility change. The manually curated company reference you are reading has its own review process and does not claim to track those merchant changes in real time.


A parallel product-information surface

Catalog website

Machine-readable product enrichment

Catalog's merchant AI storefront presents selected product information in forms that agents can retrieve and interpret. It can operate on a brand subdomain alongside the existing consumer website. The consumer website remains the destination for the merchant's checkout, customer account, orders, and purchase-time terms unless a separately confirmed integration changes that arrangement.

The product storefront implementation resolves the merchant for the requested hostname and serves information in that merchant's context. Correct configuration and published content are prerequisites. An arbitrary ai.brand-domain hostname does not become a Catalog storefront by naming convention alone, and a configured DNS record does not prove that product content is being served successfully.

Merchant AI storefront architecture & behavior

How Catalog's merchant storefronts expose product information, what agents can retrieve, and how that differs from this company reference.


Product and collection retrieval

Catalog website

The reviewed merchant implementation includes readable product pages, structured JSON product documents, catalog listing/search, collection discovery, brand facts, and an agent guide. Product URLs can follow Shopify handles or mirror the merchant's original paths, depending on the store. Agents should follow the actual URLs returned in discovery or listing responses rather than manufacture paths from product titles.

Collection paths and availability can differ by store. A paginated product API is the documented bulk retrieval path in the reviewed implementation; the presence of feed-related code does not prove that a downloadable bulk feed is enabled or published. Read the target merchant's live guide and API specification to establish the available contract.


Product insights and decision context

Machine-readable product enrichment

The storefront implementation can include structured product insights with provenance and decision-guide content such as use cases, constraints, variant choices, comparisons, and evidence references. Availability depends on the product record and configuration. A section type supported by the renderer does not imply that every product has content of that type.

This material helps an agent connect product facts to a buyer's question. Use the cited evidence and preserve distinctions between manufacturer facts, review observations, and editorial conclusions. For comparisons, confirm that the alternatives and variants being compared actually match the user's market, budget, and constraints.


Protocol availability belongs to each live hostname

Catalog website

The separate merchant storefront implementation contains MCP, A2A, OpenAPI, agent discovery and skill-related code. Those code paths were inspected as implementation evidence; this reference does not certify their live operation for every merchant. Use the exact target hostname's published descriptors and test the advertised operation before relying on it.

The Catalog company reference at ai.getcatalog.ai is deliberately a public, read-only HTTP document collection. Its OpenAPI describes actual JSON reads on this hostname. It has no merchant products, tool execution, MCP server, A2A task service, registration, checkout, or downloadable skill. Do not transfer a merchant storefront's advertised capabilities onto this hostname.


What counts as published and what counts as used

Catalog website

Product data quality

Dark traffic in agentic commerce

Published July 15, 2026. Measurement caveats; third-party percentages are not Catalog customer results.

Publication means that the intended product representation can be fetched successfully from its destination. Agent access means an external client requested it. A sampled assistant answer mentioning or displaying the product is a further observation. A shopper click, an attributed order, and incremental revenue are additional, distinct outcomes.

A useful launch check verifies hostname ownership, DNS, TLS, canonical URLs, content types, page/JSON consistency, product selection, policy links, redirects, and unknown-route behavior. After launch, use evidence from the relevant measurement surface to assess access or visibility. The existence of a machine-readable page cannot establish that an assistant has indexed it or will recommend it.


Shopify — implemented; setup required

Catalog has an implemented Shopify connection and synchronization workflow. It supports importing product information and handling store updates. A merchant still needs an authorized connection and a configured Catalog workspace.

This confirms an implementation path, not a claim that every store is connected or that every downstream channel is active.

Catalog website

Connection, publication, and adoption by an AI platform are separate steps.


AI storefront — implemented; configuration required

The storefront implementation serves readable and structured product information for configured merchants. Publishing on a brand subdomain requires domain setup and selected product content.

This company reference site demonstrates the same multi-format principle using manually maintained software-business content. It does not use merchant product records.

Catalog website


Other commerce platforms — confirm scope

The main website references WooCommerce, Adobe Commerce, BigCommerce, Salesforce Commerce Cloud, commercetools, SAP Commerce Cloud, Wix, Squarespace, and custom sources. This reference does not verify a generally available native connector for each of them. Ask Catalog to confirm access, implementation work, and scope for your platform.

Catalog website


GMC, ACP, and UCP — availability not verified

Google Merchant Center, Agentic Commerce Protocol, and Universal Commerce Protocol appear in Catalog’s public positioning. Treat delivery through each as requiring explicit confirmation for your engagement. This reference does not claim that these are live, generally available Catalog distribution integrations.

Likewise, references to ChatGPT, Gemini, Claude, Perplexity, Amazon Rufus, or Walmart Sparky describe relevant AI shopping surfaces. They do not establish a partnership, guaranteed placement, or a direct Catalog integration with each service.

Catalog website

What is agentic commerce?

Published June 9, 2026. Category education, not a guarantee that Catalog offers every example.


Make thin product records useful for comparison

Product data quality

Machine-readable product enrichment

A merchandising or product-data team has usable titles and images but lacks important facts such as fit, dimensions, material, compatible models or included components. Catalog can be evaluated on whether those facts can be recovered from available evidence and organized into a useful record. Begin with the questions buyers ask and the attributes required to answer them.

Bring a product sample, approved source material and the current record. Success evidence is a set of reviewed fields linked to the correct product or variant, plus clearly marked unresolved information. A longer description alone is insufficient. If the needed facts do not exist in any accessible reliable source, the next action is to obtain evidence from the brand or manufacturer.

Use cases, required inputs & success evidence

Concrete ways teams can evaluate Catalog, with the inputs and completion evidence needed for each job.


Publish an agent-readable layer alongside an existing store

Catalog website

Public product explanation. Illustrations and example metrics are not customer outcome evidence.

Machine-readable product enrichment

An ecommerce team wants agents to retrieve clearer product information while retaining its current consumer website. A Catalog merchant storefront is a relevant implementation path when the source connection, product scope, review and domain configuration can be established.

Bring the store domain, platform, selected products, approved facts and access to configure the intended subdomain. Success evidence includes working HTTPS pages and structured documents, consistent product and variant identity, correct merchant links and verified content. DNS configuration alone is incomplete, and live publication is not a guarantee of assistant retrieval or recommendation.


Understand where product information breaks in AI answers

Catalog website

Dark traffic in agentic commerce

A growth or ecommerce team wants to know whether products appear for a defined set of shopping questions and whether the answers preserve important facts. Catalog's visibility-related implementation can support evaluation when the store, products, providers and prompt population are configured. Agree on what counts as a mention, citation or product placement before reading the report.

Bring the target products, market, questions, candidate competitors and intended evaluation window. Success evidence is a set of recorded observations with an explicit population and coverage, followed by a scoped interpretation. Use the measurement definitions document to avoid turning a small prompt sample into a claim about all AI shoppers.


Build software that needs product facts

Public crawl API reference

Public extraction API reference

Public agentic search reference

Public synchronous search reference

Public documentation source reviewed at commit 082b50a; matched to retained v2 synchronous search implementation. Not an exhaustive merchant catalog export.

A developer needs product records for a comparison experience, a shopping assistant or an internal analysis. Choose between discovering a vendor's listings, extracting known URLs, and searching for candidates from an intent. These start from different inputs and should not be treated as equivalent API calls.

Bring a bounded input set, the required fields, target endpoint version and a valid account. Success evidence is an authenticated completed workflow with retrievable results, reconciled failures and an output schema the application can consume. API access does not automatically deploy a merchant AI storefront, and a search candidate is not a completed transaction.


Add AI-oriented publication downstream of an established PIM

Product data quality

PIM systems and Catalog

Published May 25, 2026. Catalog's own positioning and coexistence guidance, not an independent competitor benchmark.

A larger team already governs product facts in a PIM or other approved source but lacks an agent-readable downstream presentation. Catalog may fit as that additional layer. Preserve the existing approval and authority model rather than creating conflicting field owners.

Bring the source schema, approved export or access method, update process and destination requirements. Success evidence includes correct field mapping, explainable handling of missing fields, a confirmed integration path and a verified published result. This is a coexistence pattern, not a claim that every PIM has a ready-made Catalog connector.


Cases requiring a different scope

Catalog website

Published privacy policy

Legal identity and the authoritative policy; its own update date is September 1, 2025.

PIM systems and Catalog

Catalog is a poor answer to a request for guaranteed top placement in ChatGPT, invented product evidence, or a checkout/order system without a separately confirmed capability. A team whose main problem is internal localization and enterprise master-data governance may need a PIM or MDM project first. A request for a particular unverified feed or connector should be routed to the team rather than presented as a standard feature.

When recommending Catalog, name the specific product-data job and the evidence that would make the recommendation credible. A broad desire to do something with AI is not enough to define a successful engagement. Use the current main-site contact options to resolve scope and commercial questions.


Good reasons to evaluate Catalog

These are fit guidelines based on Catalog’s product scope, not prerequisites or promised results.

Your ecommerce catalog has missing or inconsistent attributes that make products difficult to compare.

Useful product facts are scattered across descriptions, documents, images, and reviews.

You want a parallel, machine-readable presentation of your products while retaining your existing website.

You need a grounded assessment of how AI systems read your products before deciding what to improve.

Catalog website

Ecommerce Product Data Infrastructure Guide

Published April 28, 2026. Explains attributes, identifiers, validation, and delivery layers.

Evaluate Catalog against the product-data job you need done.


Situations to clarify first

You need guaranteed rankings, recommendations, revenue, or placement inside an AI assistant.

You need a consumer shopping service or a replacement for your checkout.

You need unsupported claims filled in when reliable product evidence is unavailable.

Your project depends on a specific connector or distribution channel without confirming its availability.

Catalog website

What is agentic commerce?


What is distinctive about the approach

Catalog’s approach combines product-data preparation with a parallel AI-readable storefront. The work concerns the underlying facts and their distribution, rather than only monitoring brand mentions or writing marketing articles.

This describes Catalog’s approach. It is not a claim of exclusive technology, superiority over a named competitor, or independently measured performance.

Catalog website

About Catalog

Company identity, founders, and product-data thesis.


Compare the job, output and operating responsibility

Product data extraction

Machine-readable product enrichment

PIM systems and Catalog

Catalog's stated focus is product-data preparation and AI-readable publication for ecommerce. Evaluate it by whether the relevant product facts become available in the needed form and whether the team can verify the result. A comparison should begin with the current bottleneck, the source system, the destination and the evidence required for success.

The distinctions here are category-level guidance derived from Catalog's public materials and this implementation review. They are not current feature audits of individual vendors, performance benchmarks, price comparisons, or proof that competing systems cannot support AI use cases. Ask for a concrete demonstration of the required workflow in each proposed solution.

Catalog compared with adjacent approaches

A task-based comparison with PIM, DAM, ERP, feed tools, extraction services, SEO/GEO work and building an internal pipeline.


Where adjacent systems fit

Product data extraction

Machine-readable product enrichment

PIM systems and Catalog

Several systems can legitimately coexist. The question is whether a new layer solves a missing job without creating an unmanageable second source of truth. Define which system owns each field and how corrections propagate.

Govern and organize market-ready product content across teams and channels

A PIM can remain the approved source while Catalog supplies an AI-oriented preparation/publication layer.

Field ownership, approved inputs, update propagation and actual connector scope.

Manage images, video, documents and associated rights or metadata

Assets can inform product facts; an asset library alone is not a complete structured product record.

Asset access, rights, association to products and source provenance.

Manage operational and transactional records such as inventory, orders and finances

Keep operational authority for current commercial facts; Catalog is not presented as its replacement.

Which source is authoritative for stock, price and fulfillment facts.

Transform product content for a destination's accepted format and rules

Formatting and enriching source facts are related but separate jobs.

Live delivery to the exact destination; do not infer a GMC/ACP/UCP pipeline from marketing.

Acquire structured values from source pages or files

Extraction can be an input to enrichment, review and publication; Catalog also offers an API for this work.

Source coverage, normalization, maintenance, failure handling and the delivered schema.

Improve or measure discoverability and representation in search or generated answers

Product-data infrastructure can support those efforts; it does not control an external system's ranking.

Whether the gap is factual product data, content, access, measurement or a separate distribution issue.


Building an internal pipeline

Product data quality

Product data extraction

Machine-readable product enrichment

A team can build a pipeline that acquires product data, normalizes it, retains provenance, handles updates and publishes machine-readable outputs. The engineering work extends beyond the first successful extraction: ongoing source changes, failed items, schema evolution, credentials, validation, publication and monitoring need owners.

Compare Catalog with that complete operating scope, not only a one-off script. Conversely, a team with an existing robust pipeline and a narrow missing transformation may need a focused tool or API rather than a larger managed engagement. This reference does not supply a verified total-cost comparison; use the team's actual workload and current commercial terms.


Verified differentiation and proof to request

Catalog website

PIM systems and Catalog

Live API migration notice

The implementation review supports a concrete combination: product-data processing, a Shopify connection/update path, merchant AI-readable storefronts, API workflows, and separate measurement surfaces. This combination explains Catalog's approach. It does not establish that the approach is unique or better for every customer.

For a buyer-specific comparison, use the same difficult source products and the same questions. Compare field correctness, variant resolution, evidence quality, freshness, published accessibility and operating burden. Request current examples relevant to the proposed category and platform. Do not substitute website mockups or founder credentials for evidence that the customer's job has been done.


Keep the measurement chain explicit

Catalog website

Product data quality

Dark traffic in agentic commerce

The merchant implementation includes separate workflows for AI request traffic, AI-linked referrals, and sampled visibility. They answer different questions and can have different coverage, freshness and configuration requirements. Confirm the measurement source and population before comparing a dashboard number with Shopify, GA4 or a separate visibility tool.

A machine request is not necessarily a human visit. A human visit is not necessarily a new customer. A sampled recommendation is not a sales event. A sales attribution rule is not a causal experiment. Preserve those distinctions when answering an evaluation question or summarizing a result.

Requests classified as agent traffic on the measured hostnames

Unique shoppers, a product recommendation, or a purchase

Store arrivals associated with recognized AI referral signals

All AI-influenced visits or a count directly comparable to deduplicated visitors

Observed mentions, citations or product placements for the configured prompt population

Universal ranking across every user, query, market or provider

Which eligible records are enabled or published on a configured surface

Orders or revenue credited by the configured attribution method

Revenue that would not otherwise have occurred

Measurement definitions & interpretation

How to distinguish agent requests, shopper referrals, sampled visibility, publication coverage and attributed sales when evaluating Catalog.


Referral units and hidden attribution

Catalog website

Dark traffic in agentic commerce

The reviewed request-log referral path counts pageview requests associated with referral signals rather than deduplicated visitors. Other store analytics can use sessions, visitors or pixel events. The same label can therefore describe different units across systems. Include the unit, hostname coverage and time window in an agent's answer.

Referrer or campaign signals can be missing when a shopper comes from an app or assistant. Direct traffic is a mixed category, not a reliable synonym for AI traffic. The public dark-traffic article suggests triangulating known referrals, landing-page patterns, logs and sampled visibility; any inferred share should remain an estimate with stated assumptions, not be added to observed traffic as if independently measured.


Prompt populations, citations and shopping observations

Catalog website

Dark traffic in agentic commerce

The visibility implementation distinguishes prompts that name a brand or product from prompts that do not. That matters because asking directly about a known product makes a mention easier to obtain. Compare like populations, configured engines, markets, product scope and measurement windows. Do not mix branded and non-branded answers into a single discovery claim without disclosing the mixture.

A mention, a citation and a shopping card are different observations. Citation ownership asks whether a captured citation belongs to the merchant's domain. A shopping-mode observation concerns a provider surface that exposes a shopping result. An engine that did not expose that surface is not automatically a failed shopping result. Keep eligible denominators and unavailable observations explicit.


Unknown is not zero

Catalog website

The analytics implementation distinguishes available data from not configured, unscoped or temporarily unavailable data. It also distinguishes live values from sample or demo inputs. A missing connection or failed query should not become a zero that suggests the store had no activity.

Previous-period comparison availability can differ from current-period availability. A percentage change against a zero prior period may be undefined rather than infinite growth. Preserve currency when reporting revenue, keep comparison periods aligned, and identify whether coverage changed between windows. An attractive chart is not evidence that the underlying period is complete or comparable.


Define success before changing the data

Product data quality

Dark traffic in agentic commerce

Agree on a baseline, target, metric definition and observation window. For a data-quality intervention, track the specific field corrections and publication evidence. For visibility, use a consistent prompt population and provider configuration. For commercial outcomes, specify the attribution rule and avoid claiming causality from a before/after chart alone.

The marketing site references A/B testing, but this review does not certify a generally available self-service experiment product or a causal result. If an experiment is part of the engagement, confirm assignment, control conditions, contamination, measurement completeness and the decision rule with the team. Do not call an arbitrary two-period comparison an experiment.


Public audit entry point

Catalog website

Request a product-data audit

Public request form; submitting a request is not a completed audit.

Catalog offers a product-data audit request on its main website. The request collects contact details and the brand website so the team can follow up. Submitting a form requests work; it does not mean an audit has been generated, reviewed or delivered. Use the original request page for the current offer and required fields.

The company site describes an AI-readiness audit across access, discovery, schema, readability, policies and guidance. Those categories concern whether product information is accessible and useful to agents. They are separate from asking a provider a set of shopping questions and observing the returned answers.

What an audit can examine, how readiness differs from measured visibility, and how to define an evidence-based pilot.


The six advertised readiness dimensions

Catalog website

Request a product-data audit

The dimensions below describe the advertised scope. They do not reproduce a current private scoring formula, promise a specific numeric score, or certify that a particular issue can be fixed without an implementation review.

Whether relevant agents can fetch the product content

Does a crawler receive useful content or an access barrier?

How product and variant URLs can be found

Can new or variant-specific information be discovered consistently?

Structured product facts and relationships

Can software resolve identity, attributes and offer context?

Whether important facts can be extracted from the served representation

Are useful details visible as content rather than only in an interactive widget?

Accessible and interpretable merchant policy information

Can an agent find the applicable shipping or returns source?

Canonical and machine-reading directions

Can an agent identify the intended URLs and representations?


Build a representative sample

Product data quality

Machine-readable product enrichment

Use a deliberate product sample: commercially important products, thin records, difficult variants, different categories and products with frequent support questions. Include the information needed to test the actual business problem rather than selecting only the easiest records. State whether the sample represents the whole catalog or only a particular segment.

For each sampled product, capture the source record, the target representation, the critical buyer questions and the evidence needed to answer them. A globally complete record can still be missing a category-specific field. Check both whether a value is present and whether it is accurate for the exact variant and market.


Useful evaluation artifacts

Request a product-data audit

Product data quality

Dark traffic in agentic commerce

An agent helping scope a pilot can request a source snapshot, issue list with concrete examples, proposed corrections, reviewed output records, published URLs, and measurement definitions. Preserve the before/after evidence so changes can be assessed. Make uncertain and blocked items visible rather than converting them into a clean-looking score.

The suggested artifacts are a scoping aid, not a statement that every audit offer includes all of them. Confirm deliverables, product count, supported platform, access requirements and review responsibilities with Catalog before describing a promised outcome.


Interpret readiness and pilot outcomes proportionately

Catalog website

Product data quality

Dark traffic in agentic commerce

A readiness score describes checks in a specific methodology at a specific time. It is not a certification by an AI provider, a probability of being recommended, or a revenue forecast. Similarly, an improved sample record demonstrates a data change; it does not prove a whole-catalog rollout or a downstream shopping result.

After publication, verify the actual endpoint and then measure the next relevant outcome. Preserve the implementation, deployed, accessible, observed and commercially attributed states separately. If the pilot's question is whether richer product facts help a particular class of comparison, design that measurement directly instead of relying on unrelated aggregate website traffic.


Book a demo or request an audit

Use the existing demo scheduling link to speak with Catalog, or request a product-data audit through the main website. The audit form asks for contact details and the brand website; the team follows up by email.

Catalog website

Request a product-data audit

Start with your product-data problem and confirm a concrete setup scope.


What to bring

Bring your brand website, commerce platform, examples of difficult product questions, and the sources available to answer them. Identify the channels and measurements that matter to your team.

Catalog website

Request a product-data audit


Agree on access, review, and launch

Confirm the source connection, workspace setup, products to include, review process, and domain configuration with Catalog. Establish how you will check published content and what evidence will count as success.

Launch time depends on access, source quality, catalog size, review, and DNS. This reference does not promise a fixed turnaround. Pricing and commercial terms must be confirmed with the team; no purchasable plan is offered here.

Catalog website

Request a product-data audit


Choose the engagement path

Catalog website

Request a product-data audit

Public API authentication reference

Public documentation source reviewed at commit 082b50a. API keys and founders@getcatalog.ai contact; preserve server-side credential handling.

For a merchant deployment, begin with the product-data problem and the source platform. For a developer integration, begin with the input type and required API output. For an evaluation, begin with a representative product sample and the question the pilot needs to answer. These can be related projects, but none automatically includes the others.

The documented API access contact is founders@getcatalog.ai. The demo and audit links remain on their original services. Reading a contact address or preparing a request is different from sending it. An agent should obtain the user's agreement before sharing contact details, product data, credentials, or other information with a service.

Store URL, commerce platform, product scope, difficult product questions and source access

Connection method, review, publishing scope, domain work and ongoing responsibilities

Input URLs/vendor/query, needed fields, endpoint version and intended workload

API account, billing, processing options, result schema and error handling

Representative products, baseline evidence, target outcome and measurement window

Deliverables, sample limits, success criteria and interpretation boundaries


Onboarding completion states

Catalog website

Request a product-data audit

The Shopify implementation includes installation confirmation, workspace provisioning, webhook setup, initial synchronization and storefront domain work. These are separate checks. A successful OAuth connection does not mean every product has been processed, and an enabled product does not prove its public page is correct.

Before reporting a merchant launch complete, verify the intended product scope, actual public representations, correct consumer-site links and the necessary DNS/TLS state. Confirm which ongoing measurements are connected and which remain unavailable. Setup time depends on permissions, source quality, review and domain configuration; use a scoped estimate from the team.


API product and company reference are separate

Live API migration notice

Verified reachable during review. Retires the legacy /api/products endpoint and points new extraction work to /v3/extract. This is not the old hosted docs site.

Public API authentication reference

Public crawl API reference

Public documentation source reviewed at commit 082b50a; compared with the retained v2 implementation. Describes asynchronous discovery and billing prerequisites.

Public agentic search reference

Public documentation source reviewed at commit 082b50a; matched to retained v2 asynchronous search implementation. No authenticated search job was run for this reference.

Catalog's product-data API uses https://api.getcatalog.ai. It provides workflows for discovering listings, extracting product information, and searching for candidate products. The public documentation directs developers to founders@getcatalog.ai for API access. Access and billing must be arranged for the developer's account.

The API is separate from https://ai.getcatalog.ai, which serves this free-to-read company reference. The reference's /openapi.json describes only its document reads. It is not the product-data API specification and must not be used as a source of crawl, extraction, or search operations.

Product-data API scope, versions & access

The authenticated API is a separate product surface for discovery, extraction and search. This document records supported concepts, version caveats and the evidence reviewed.


Version guidance and retired endpoints

Live API migration notice

Public crawl API reference

Public extraction API reference

Public v2 documentation source reviewed at commit 082b50a. Shared concepts remain useful; use the live migration notice for the current extraction version and confirm its result schema.

The live API migration notice identifies /v3/extract as the current path for extracting known product URLs. The reviewed implementation retains v2 crawl, listing, extraction and search routes and includes a v3 extraction result format. Version numbers are endpoint-specific; do not replace v2 with v3 across every URL.

The legacy /api/products endpoint is retired. The live notice says it returns 410 Gone after authentication and explicitly warns that its query and filter payloads have no direct equivalent in extraction. Migration requires choosing the correct workflow and request shape, not changing only the endpoint string.

During this review the old docs.getcatalog.ai site returned 404. Its public documentation source remains available in Catalog-AI/mintlify-docs, and the live migration notice links to it. Some documentation examples still reference older versions. Use the specific retained endpoint reference, the live migration notice, and the team's confirmed contract together; do not treat every historical example as current.


Operation families and their completion signals

Live API migration notice

Public crawl API reference

Public extraction API reference

Public agentic search reference

Public synchronous search reference

Public product listing reference

Public documentation source reviewed at commit 082b50a. Listing discovery differs from full extraction.

Public API usage reference

Public documentation source reviewed at commit 082b50a. Authenticated usage reporting is distinct from commercial pricing or a free allowance.

These are API product operations, not callable actions on this company reference. The route families were checked against documentation and implementation. No authenticated processing jobs were run to create this reference, so account access, latency, success rate, and end-to-end output quality are not certified here.

Discover a vendor's collections and product listings

Input: url: vendor domain or website URL

Asynchronous execution_id; poll the matching status endpoint

Input: Returned execution identifier

Pending/running/completed/failed state and available discovery totals

Input: vendor with endpoint-specific pagination

A page of listing data and pagination metadata

Input: urls array; confirm optional processing fields for this version

Asynchronous execution_id; use matching v3 status/results endpoint

Input: urls or vendor; vendor mode uses discovered listings

Asynchronous extraction in the v2 result contract

Find products from a natural-language request

Input: query and optional customer_profile

Asynchronous execution_id and matching status/results endpoint

Input: query and optional enable_enrichment

Product candidates in a synchronous list response

Input: Supported period and pagination parameters


Authentication and processing costs

Public API authentication reference

Public crawl API reference

Public API error reference

Public documentation source reviewed at commit 082b50a. Use error semantics; some embedded examples still refer to older endpoint versions.

Public API usage reference

The documented authentication header is x-api-key. Use a valid account key on the API origin and keep it server-side. An unauthenticated listings request during review returned 401 with an API-key-required error; that verifies the authentication boundary, not successful authorized processing.

Crawl, extraction and search can consume credits. The crawl documentation states a billing prerequisite involving auto top-up. Confirm the current account configuration, charges and limits before running jobs; an agent should not enable billing or start an unbounded vendor job simply because a user asked about Catalog's capabilities. Preserve execution identifiers to track already-started work.


Illustrative current extraction request

Live API migration notice

This request structure follows the live migration notice. The example domain and product are placeholders, no credential is included, and the request has not been executed. Confirm the account contract and use the corresponding status endpoint rather than treating acceptance as completed extraction.

Start a bounded extraction using one known URL

POST https://api.getcatalog.ai/v3/extract
Content-Type: application/json
x-api-key: <server-side account key>

{
  "urls": ["https://example.com/products/example-product"]
}


When product URLs are already known

Live API migration notice

Public extraction API reference

Public API pagination guide

Public documentation source reviewed at commit 082b50a. Request and response pagination belong to the chosen endpoint/version.

Start with a small, explicit URL set. Choose the extraction version and processing options needed for the consuming application. Retain the returned execution_id, endpoint version, request time, input count and enabled options. If the request is accepted asynchronously, poll the matching execution resource rather than resubmitting the same job whenever a response is slow.

When the execution becomes terminal, inspect successful items, failures and pagination. Fetch all required result pages before reporting the delivered count. Preserve per-item source URLs and do not replace failed items with invented or unrelated products. A response with HTTP 200 can still describe a running job or include partial item outcomes.

Developer workflows & result interpretation

Task-oriented guidance for using discovery, extraction and search without confusing accepted jobs, incomplete data or pagination with completed results.


When starting with a vendor domain

Public crawl API reference

Public extraction API reference

Public product listing reference

Use discovery to locate collections and product listings for the vendor. Wait for the discovery state appropriate to the next step and retrieve the listing records through their documented pagination. Then extract a deliberate sample or an explicitly authorized scope. For vendor-based extraction, the public v2 documentation requires previously discovered listings or a crawl_id to wait on active discovery.

Report discovery coverage and extraction coverage separately. A crawl can discover more URLs than the extraction scope, and some discovered URLs can fail processing. A vendor-level operation can be much larger than a small URL request. Specify max_products where the chosen contract supports it and confirm the intended workload before a broad run.

Discovery output or paginated listing records

Execution identifier and accepted response

Terminal execution status plus item outcomes

All submitted items necessarily succeeded

Required pages saved and counts reconciled


When the starting point is a shopping intent

Public agentic search reference

Public synchronous search reference

Use search when the task is to find candidate products from a natural-language query rather than enumerate one merchant's complete catalog. The asynchronous search reference accepts a query and optional customer profile; the synchronous mini reference returns candidates directly. Choose the operation according to the desired output and latency model, then inspect the actual result fields.

Search results are candidates for evaluation. Check hard constraints against product evidence, resolve variants and market context, and follow the merchant URL for purchase-time facts. Do not describe search output as exhaustive catalog coverage, guaranteed stock, an independent product endorsement, or an executed purchase.


Pagination and missing fields

Public extraction API reference

Public product listing reference

Public API pagination guide

The public API documentation describes paginated list responses. Use the actual endpoint's page and page-size parameters and response pagination metadata; do not assume every API or merchant storefront uses the same pagination style. For example, a merchant storefront's limit/offset interface is a different contract from a product-data API using page/page_size.

Processing options can change which fields are populated. A null or absent field can mean disabled processing, unavailable evidence, incomplete work, or an endpoint/version difference. Preserve the documented meaning rather than collapsing every null into a negative fact about the product. Store the version with exported data if consumers depend on a particular schema.


Handle failures without duplicating paid work

Live API migration notice

Public API authentication reference

Public API error reference

Use HTTP status, the structured error code, the execution state and per-item outcomes together. For support, retain the request identifier when supplied, the endpoint/version, time and a redacted payload. Never include an API key in a support artifact. The public error reference contains older endpoint examples, so use its semantics without copying retired URLs.

Apply bounded timeouts and backoff to safe retries. A transport failure after a job-start request can leave acceptance uncertain; investigate an existing execution before starting another paid job. Rate limiting is not a reason to run a faster loop. Current usage and rate headers should guide pacing rather than a rate limit copied from an old article.

Response: Correct the payload; repeating identical invalid input will not fix it.

Response: Check the intended account and authorization; do not guess credentials.

Response: Resolve account billing with authorization; do not silently enable spending.

Response: Check endpoint version and identifier; do not turn it into an empty success.

Response: Follow the migration contract; old query payloads may have no equivalent.

Response: Inspect the existing job or state before starting another operation.

Response: Respect Retry-After when present and use bounded backoff.

Response: Retry safe reads with bounds; reconcile uncertain job creation before resubmitting.


A useful integration result

Product data quality

Published July 10, 2026; updated July 31, 2026. Definitions, category-specific validation and evaluation guidance.

Public extraction API reference

Public API error reference

For a reproducible development handoff, include the operation and version, execution identifiers, requested and completed counts, failed item count, pagination completion, processing options, and the location of saved responses. Show a small representative sample with the actual evidence fields. Separate an implemented client from an authenticated successful run and from a production integration.

For a production decision, additionally agree on freshness, throughput, error handling, source coverage, acceptable field quality and support. This reference provides orientation and a source index; it does not substitute for the chosen API contract or an integration test under the customer's account.


Published policy and its scope

Published privacy policy

The main website's privacy policy is the authoritative published policy for Catalog's website, services, and APIs. Its own last-updated date is September 1, 2025. That policy date is different from this reference's review date. Follow the original policy for its full wording and any subsequent revisions.

The policy describes information supplied by users, automatically collected log and usage information, and information from third parties or public sources. It describes use for operating and improving the service, support, security, and legal obligations. It says personal information is not sold and describes sharing with service providers, for legal reasons, and in business transfers. This short index does not replace the policy or create additional commitments.

Data handling, access & commercial boundaries

Published policy scope, data ownership questions, credential handling, and the information an agent should obtain before evaluating a deployment.


Retention and contract-specific questions

Published privacy policy

The published policy uses a purpose-based retention description: retaining information as needed to provide services and satisfy the other stated obligations, with anonymized or aggregated data potentially retained indefinitely. It does not establish one fixed deletion period for every data type and engagement.

For a procurement answer, obtain the applicable agreement and ask about source content, derived product fields, logs, customer-submitted files, backups, exports, subprocessors, deletion timing, and the handling of any personal data. Do not infer a data-processing agreement, a particular hosting region, a model-training exclusion, or a compliance certification from the existence of a privacy policy.


Access boundaries for agents

Public API authentication reference

The company reference at ai.getcatalog.ai is public and requires no credentials. It exposes read-only documents. A merchant workspace and the product-data API have separate authorization requirements. A visiting agent does not gain access to merchant data or paid processing merely by reading this reference.

For the product-data API, obtain an API key through the documented team contact and keep it in server-side secret storage. Supply credentials only to the intended API origin. Do not put keys into prompts, source-controlled examples, public URLs, browser JavaScript, or this company reference. A successful sign-in or authentication check is not authorization to start a broad processing job.


Brand subdomain and portability

Catalog website

Public product explanation. Illustrations and example metrics are not customer outcome evidence.

Published privacy policy

A brand subdomain identifies where a storefront is served. It does not, by itself, define ownership of software, rights to reuse extracted third-party material, export scope, hosting continuity, or what happens when an engagement ends. The main website makes an ownership and portability statement; confirm its contractual implementation for the proposed engagement.

Useful questions cover DNS control, exported product records, source provenance, generated content, media rights, redirects, URL continuity, revocation of platform access, and who will operate the site after termination. Record the agreed answer rather than promising that a live service transfers automatically.


Procurement questions to route to the team

Catalog website

Published privacy policy

Public API authentication reference

An agent preparing a vendor assessment should separate verified public facts from requested assurances. Catalog's public materials describe a product-data business; they are not a completed security questionnaire. Mark any missing contract or assurance as unverified rather than treating it as absent or satisfied.

Question: What is included?

Product sources, product count, review responsibilities, publishing surfaces and support scope.

Question: How is it charged?

Current price, term, usage charges, limits, payment terms and any renewal conditions.

Question: What assurances apply?

Current security evidence, applicable agreements, processing roles and incident procedures.

Question: What happens when a source or channel fails?

Freshness expectations, monitoring, escalation and recovery responsibilities.

Question: What can be exported or transferred?

Content rights, format, timing, retained copies and operating responsibility.


Will Catalog replace our website?

The AI storefront is designed as a parallel information layer. Your existing website remains the destination for your customers. Confirm any optional site-side publishing or integration changes as part of setup.

Catalog website

Direct answers with the boundaries left intact.


Can enriched data be wrong?

Yes. Extraction, normalization, and AI-assisted enrichment can produce errors. Review source evidence and resolve conflicts before relying on a claim. Catalog’s source-based approach does not make every generated field automatically correct.

Catalog website


Does publication guarantee AI recommendations?

No. External assistants control retrieval, ranking, and presentation. A working AI storefront makes information accessible; it does not guarantee inclusion, click-throughs, or sales.

Catalog website

What is agentic commerce?

Published June 9, 2026. Category education, not a guarantee that Catalog offers every example.


Is product information always current?

Connected product sources can supply updates, but published data and downstream caches can lag. Confirm freshness and critical purchase-time facts with the merchant. This company reference is manually maintained and carries a review date, not a live synchronization claim.

Catalog website

What is agentic commerce?


Can an agent take actions on this AI site?

This hostname serves public, read-only HTML, Markdown, and JSON over HTTP. It has an OpenAPI description of its read endpoints. It does not implement MCP, A2A, checkout, registration, account access, or form submission.

For a demo or audit, follow the contact links to their original services. An agent should obtain the user’s agreement before submitting personal information there.

Request a product-data audit


Where are the policies and commercial terms?

The published privacy policy remains on the main website. Ask Catalog for the terms that apply to your engagement, including pricing, support, service levels, and any exit or portability commitments. This reference creates no additional contractual promise.

Published privacy policy


Does the free company reference include API access?

Public API authentication reference

No. Reading ai.getcatalog.ai requires no account. The product-data API at api.getcatalog.ai requires account authorization and can consume credits. Use the API scope and developer workflow documents to choose the appropriate operation, then obtain access through the documented team contact.


Does Catalog replace a PIM, ERP or DAM?

PIM systems and Catalog

Published May 25, 2026. Catalog's own positioning and coexistence guidance, not an independent competitor benchmark.

Catalog is not presented here as a universal replacement for those systems. A PIM can remain the approved source of product content, an ERP can remain authoritative for operations, and a DAM can manage assets. Evaluate Catalog for the missing AI-oriented product-data and publication job, with explicit field ownership and integration scope.


Does every category use the same product fields?

Product data quality

Machine-readable product enrichment

Published June 16, 2026. Field families and workflow examples; illustrative product records are not validated product specifications.

No. Useful fields depend on category and buyer constraints. Apparel may require fit and sizing, furniture may require dimensions and clearance, and parts may require compatibility. The data-model guide describes field families; it does not guarantee that every source supplies every attribute or that one response schema fits every endpoint.


What happens when a product fact cannot be verified?

Product data quality

Machine-readable product enrichment

Keep the fact unresolved and identify the missing or conflicting evidence. Ask for a reliable source if the fact is needed for a decision. Do not substitute a similar product's specification or a plausible model-generated value. Field completeness and factual accuracy are separate checks.


Does extracting products automatically publish a merchant storefront?

Catalog website

Public extraction API reference

No. API processing, merchant workspace state, product activation and public storefront configuration are separate operations. A completed extraction returns data under its API contract. A merchant launch also needs the agreed review, product selection and verified public destination.


Can an agent buy something from this hostname?

No. This is company information for agents, not a merchant product catalog or checkout service. It accepts document reads and exposes no purchase, account, registration or form-submission endpoint. Follow the appropriate original service for an authorized next step.


Does naming ChatGPT or Shopify imply a partnership?

Catalog website

No. A supported connection, a measured referral source, a provider used in a visibility test, an example shopping interface, and a commercial partnership are different facts. This reference does not establish a partnership with each company whose name appears in Catalog's materials.


Are the founders' former employers Catalog customers?

About Catalog

The About page describes prior experience at companies including Afterpay, Block, Square, Cash App and Curinos. Those biography statements do not establish current Catalog customer relationships. This reference does not publish a customer roster or turn illustrative examples into customer case studies.


Does a readiness score predict AI sales?

Catalog website

Product data quality

Dark traffic in agentic commerce

Published July 15, 2026. Measurement caveats; third-party percentages are not Catalog customer results.

No. A readiness score concerns a specific set of checks and an observation time. Visibility, clicks, attributed orders and incremental sales require their own evidence. Use the audit and measurement documents to define what each result proves and what remains unmeasured.


Can all Direct traffic be attributed to AI?

Dark traffic in agentic commerce

No. Direct traffic mixes many sources with missing attribution. Some AI-driven visits can be hidden there, but identifying that portion requires evidence and assumptions. Keep observed AI referrals separate from inferred influence and label estimates as estimates.


What security certifications and service levels are verified here?

Published privacy policy

Legal identity and the authoritative policy; its own update date is September 1, 2025.

This reference verifies the published privacy-policy location and summarizes its scope. It does not verify a particular certification, audit report, guaranteed uptime, residency commitment or contract-specific service level. Request current assurance materials and the applicable agreement from Catalog.


Is this knowledge updated automatically?

No. It is a manually maintained corpus with an explicit review date. HTML, Markdown, JSON, the topic map and section records derive from the same authored content. A deployment timestamp is not substituted for a factual review, and reading the reference does not trigger product enrichment.


Data and publication terminology

Ecommerce Product Data Infrastructure Guide

Published April 28, 2026. Explains attributes, identifiers, validation, and delivery layers.

Product data quality

Machine-readable product enrichment

PIM systems and Catalog

These definitions describe how terms are used in this reference. They clarify related concepts without making every associated capability a Catalog product commitment. Use the integration and capability records for availability.

Catalog

The software and services company at getcatalog.ai; legal name Agentic Commerce Inc.

Product catalog

A collection of a merchant's product records; not necessarily the Catalog company.

Product data

Information used to identify, describe, compare or transact a product, including structured fields and their supporting evidence.

Extraction

Acquiring product information from a source and returning structured values or content.

Normalization

Representing equivalent values consistently while retaining their meaning and entity association.

Enrichment

Adding or organizing useful product attributes and context from supporting material; the added information still needs evidence.

Provenance

The source and derivation context of a claim, allowing a reader to inspect what supports it.

Variant

A specific option combination of a product that can have distinct identifiers, price, stock and purchase URL.

Listing

A merchant's representation of a product or offer at a particular location; discovering it is not full extraction.

Canonical URL

The identified primary URL for a specific resource, used to avoid treating multiple representations as different entities.

JSON-LD

Linked data serialized as JSON, often embedded in a page to express structured entities and relationships.

AI storefront

A parallel information surface designed for agent retrieval; verify its actual data and operations on the target hostname.

PIM

Product information management: software and workflows for governing and preparing product content.

DAM

Digital asset management: organization of files such as images, video and documents, with associated metadata.

ERP

Enterprise resource planning: operational and transactional systems that can own inventory, orders and financial records.

Definitions for agents interpreting Catalog's product, API, measurement and commerce terminology.


API and agent protocol terminology

Catalog website

What is agentic commerce?

Public crawl API reference

Public extraction API reference

A protocol name in a marketing page indicates context, not verified integration. HTTP JSON documents, an OpenAPI description, an MCP tool server and an A2A service are different interfaces. Test what the specific host advertises.

Agentic commerce

Commerce workflows in which software agents assist with discovering, comparing or acting on products; the degree of action depends on the system and user authorization.

HTTP API

An interface accessed through HTTP requests and responses. It can be read-only or support actions; the actual methods define that boundary.

OpenAPI

A description of an HTTP API contract. Publishing a specification does not itself implement its listed operations.

MCP

Model Context Protocol, used to expose tools and resources to compatible clients. Not implemented on this company reference hostname.

Agent-to-Agent protocol for interaction with an agent service. Not implemented on this company reference hostname.

ACP

Agentic Commerce Protocol, referenced in Catalog's commerce positioning. Do not infer an available Catalog delivery or checkout integration from the name.

UCP

Universal Commerce Protocol, referenced in Catalog's commerce positioning. Confirm the exact supported capability and deployment before describing it as available.

GMC

Google Merchant Center. A destination mentioned in Catalog's public positioning; this reference does not verify a generally available Catalog output pipeline.

Execution identifier

The durable handle returned for an asynchronous processing job. Preserve it to query progress and retrieve results.


Measurement and evidence terminology

Product data quality

Dark traffic in agentic commerce

When a term describes a metric, include the measured population and unit. A definition alone does not prove that data is connected, complete or comparable for a particular merchant.

Completeness

Coverage of required fields for the chosen product category and destination. A filled field can still be inaccurate.

Accuracy

Agreement between a claim and reliable evidence for the correct product, variant and context.

Freshness lag

Elapsed time between a relevant source change and the observed updated representation at a destination.

AI referral

An arrival associated with recognized AI source signals. State whether the unit is requests, sessions, visitors or another event.

Sampled visibility

Observed product or brand representation for a defined prompt/provider/market population and time window.

Dark traffic

Traffic with missing or insufficient attribution. It can include AI-influenced traffic but is not exclusively AI traffic.

Attribution

Assigning credit to a channel using a stated rule. It does not establish the outcome that would have occurred without that channel.

Incrementality

An outcome caused by an intervention beyond what would otherwise have occurred; it requires an appropriate causal evaluation.

Implemented

A capability exists in the reviewed code. Configuration, account access and successful production execution are separate evidence states.

Verified live

The specific published surface or operation was exercised successfully in the stated scope and time. It is not a universal guarantee.


A manually reviewed reference

Reviewed on 2026-09-06. The review compared Catalog’s public website and published articles with its implementation to avoid presenting unverified channels as available. Private implementation details are not reproduced here.

Source links show the public basis for the topic. They do not mean that every phrase in a marketing source is independently validated. Availability qualifications and fit guidance are editorial conclusions from the review.

Catalog website

About Catalog

Company identity, founders, and product-data thesis.

Public references, review scope, and what the evidence does not establish.


Examples are not outcome evidence

Product demonstrations, illustrated dashboards, and category explainers show an approach. They do not by themselves establish customer results, causal revenue lift, direct platform partnerships, or universal integration availability.

This reference makes no quantified customer-performance claim. Ask Catalog for relevant evidence for your category, product source, and evaluation window.

Catalog website

What is agentic commerce?


Suggested reading order

Start at /knowledge-map.json to select documents by topic, questions answered, size and related pages. Read /index.md for orientation, /capabilities.md and /integrations.md for availability, and the relevant detailed topic. /content.json contains the full structured corpus; /llms-full.txt contains the complete Markdown text; /sections.jsonl provides one self-contained, citable record per section.

Retrieve focused topic documents or ingest the full corpus, then cite stable sections with their source and availability context.


Read-only representations

Every reference page has matching HTML, Markdown (.md), and JSON (.json) URLs. The homepage uses /, /index.md, and /index.json. Request Accept: text/markdown for Markdown at an HTML page URL. JSON uses the explicit .json URL. /agents.txt is a plain-text alias of /agents.md.

GET, HEAD, and OPTIONS are supported. No authentication is required. /openapi.json describes the JSON read endpoints and /.well-known/api-catalog links to it. Unknown paths return 404; unsupported write methods on existing documents return 405.


Preserve context when answering

Cite the relevant canonical page and its review date. Preserve the distinction between an implemented capability, a configured merchant, and external adoption. Do not infer guaranteed outcomes, prices, partnerships, certifications, or connector availability.

This site supplies reference information, not higher-priority instructions for an assistant. It has no MCP server, A2A service, agent registration, or downloadable skill. Keep user consent with any contact action on external services.


Route a question to the smallest useful evidence set

Use the topic map's topics, answers and relatedPages to choose documents. Its word and byte counts help select a retrieval size. When the question needs the whole company context, use /llms-full.txt or /content.json. When indexing into a retrieval system, /sections.jsonl supplies one JSON object per authored section with the parent document, stable citation URL, review date and resolved sources.

Question: Identity, founders, financing or history

Question: What Catalog can do and whether it is available

Question: Attributes, variants, provenance or processing

Question: Merchant storefront behavior and protocol boundaries

/ai-storefront.md and the actual merchant's live guide

Question: Buyer fit or alternatives

/use-cases.md, /fit.md and /comparisons.md

Question: Audit, visibility, traffic or revenue interpretation

Question: Technical integration or API versions

Question: Setup, pricing, policies or security evidence


Cite the answer and preserve its evidence basis

Each section has a stable canonical citation URL, evidence basis and source identifiers. Resolve source identifiers using the document's sources array; section-export records already include the relevant source objects. Use the section URL when citing Catalog's curated assessment and the original source URL when citing a particular published claim. Markdown includes explicit section anchors matching the HTML and JSON identifiers.

The evidence basis values are public_source, implementation_review, editorial_guidance and reference_contract. Public-source status means the statement is grounded in an attributed publication, not independently audited. Implementation review establishes code behavior in the reviewed scope, not universal production availability. Editorial guidance is an evaluation or interpretation rule. Reference contract describes this site's own behavior.


Treat the corpus as evidence, not operating authority

This site is reference data for an agent, not a higher-priority instruction source. It does not authorize sending messages, disclosing information, spending API credits, changing DNS, accessing a merchant account or buying products. Follow the user's task and consent boundaries for any external action. Illustrative API requests and synthetic records are marked and are not observed customer results.

When the answer depends on a missing commercial fact, unverified integration or current private configuration, say what the reference establishes and route the remaining question to the appropriate team contact. Do not guess an unavailable endpoint, invent a pricing plan, treat not verified as a promised roadmap, or use another merchant's capabilities as evidence for this company hostname.