Preflight a public commerce discovery document
Validate supplied JSON and confirm that it declares a public endpoint without attempting authentication, cart, payment, or order actions.
AI Commerce Validator
Free, no signup. Public discovery and merchant-feed readiness for agentic commerce. It does not attempt credentialed checkout.
Baseline: local-baseline-2026-07-12 · 2026-07-12
Commerce protocol baseline last reviewed Jul 12, 2026.
feed_url (also feed.url or links.feed) or merchant_id (also merchant.id) value.Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Commerce validation evidence
Next steps
- Validate Product schema
Check Product and Offer structured data separately.
- Check AI crawler access
Verify discovery files are reachable to the intended crawlers.
Rate this tool
Runs entirely in your browser — nothing you paste is uploaded or stored. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Commerce truth comparator
Does the URL, visible selection, schema, feed and purchasable item describe the same product?
How to use it
- Paste a public ACP-style discovery response, a merchant feed, or both.
- Use XML with item/entry elements or TSV with a header row for the feed.
- Select Validate. Read each pass or warning independently and note any section marked not evaluated.
- Continue with live endpoint, schema, crawler-access, account, and checkout testing outside this offline check.
Example result Example data — engine calculation
The interactive example uses fictional example.com data and returns:
pass Valid JSON discovery response.
pass Public checkout/discovery endpoint declared.
pass Required merchant-feed values are present in at least one row.
pass Sampled product IDs are unique.
pass Sampled product image URLs are absolute HTTP(S) URLs.
pass Validated 1 sampled feed row.
Feed parser: tsv.
Product/Offer schema, llms.txt, AI-crawler access, and authenticated checkout are not evaluated.What the results mean
Pass means the narrow local shape check succeeded. Warn means malformed JSON, no declared endpoint, no parsed rows, or a required value missing from the sample. Not evaluated is used for absent sections and adjacent checks outside this tool. A pass is not protocol certification.
How it works
The discovery validator parses JSON and looks for checkout_url, endpoint, or links.checkout. When you explicitly supply an expected feed URL or merchant identity, it compares that value with a corresponding discovery value. Missing values remain not evaluated; a mismatch is emitted only when both sides provide comparable evidence. The feed parser extracts up to 200 XML items/entries or TSV rows and runs deterministic shape checks.
Features
- Discovery and merchant-feed checks can run together or independently.
- Explicit XML, TSV, unknown-format, and not-evaluated states.
- Real baseline freshness disclosure and browser-only parsing.
- Interactive fictional example with no live commerce action.
Limitations
- Field presence can be distributed across different rows; it is not a row-by-row completeness guarantee.
- Feed URL and merchant comparisons assert string identity after conservative normalization; they do not prove ownership or that the URL is reachable.
- No URL fetching, schema validation, feed-policy validation, authentication, cart, payment, tax, shipping, or order testing.
- XML parsing supports a small tag set and is not a full namespace-aware feed parser.
- Protocols evolve; use the displayed baseline date when interpreting results.
Frequently asked questions
What does the AI Commerce Validator check?
It checks whether pasted discovery contentURL discovery is how search engines find URLs to crawl — by pull (following links and reading sitemaps) and by push (you notify them via IndexNow, the Indexing API, or WebSub). It's the find step that comes before a page is ever fetched. is valid JSON and declares a public endpoint, and whether a pasted XML or TSV merchant feed contains required values, unique product IDs, and absolute HTTP(S) image URLs.
Does this validate a live ACP or UCP checkout?
No. The tool is an offline public-discovery and feed-shape check. It does not authenticate, add products to a cart, submit payment, or verify order lifecycle behavior.
Which merchant feed formats are supported?
It recognizes XML item or entry elements and tab-separated data with a header row. It samples at most 200 rows and does not support arbitrary CSV.
Does a passing feed result mean every product row is valid?
No. Required-field presence is checked across the sampled rows, and the result does not validate currencies, controlled availability values, URL reachability, product schemaProduct schema (schema.org/Product) is structured data that tells search engines a page's product name, price, availability, and reviews so it can appear in Shopping-style rich results. It's separate from a Google Merchant Center feed, though Google reconciles the two., or account policy.
Is my commerce data uploaded?
No. Discovery JSON and feed text are parsed locally in your browser.
Feature requests for Ai Commerce Validator
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Compare discovery identity with an expected merchant feed
Check an explicitly supplied feed URL or merchant ID against comparable discovery values while leaving missing comparisons not evaluated.
Review a bounded XML or TSV feed sample
Check required field presence, duplicate product IDs, absolute image URLs, parser state, and sampled-row count across at most 200 supplied rows.
Reconcile product facts across customer and machine surfaces
Compare visible, schema, feed, selection, and optional cart facts field by field so disagreements remain traceable to their sources.
Create an offline readiness handoff
Share a local result card or URL-state handoff, then continue separately with live endpoints, Product schema, crawler access, account policy, and checkout testing.
Watch the full workflow
AI Commerce Validator walkthrough
Read the transcript
AI Commerce Validator
This beginner walkthrough shows how to check fictional commerce discovery data and a four-product feed before launch. We will upload the files, read every pass and warning, compare product details across several surfaces, create a handoff, and finish with the important checks this browser-only tool cannot perform.
Step 1
AI Commerce Validator is a browser-based preflight check. You give it public discovery J-S-O-N, a merchant feed, or both. It checks whether the supplied data has a usable basic shape and whether product facts agree. It does not visit the URLs, sign into an account, add an item to a cart, or test payment. A pass is useful evidence, but it is not commerce certification.
Step 2
This is useful before launching a commerce integration, after changing a feed, while investigating a merchant or feed identity mismatch, when product details disagree across customer and machine surfaces, or when you need a small review handoff. The tool only judges the text and expectations you provide, so you can use fictional or safely reviewed data without connecting an account.
Step 3
Before using the results, check the baseline date near the top of the page. This walkthrough uses the local baseline reviewed on July twelfth, twenty-twenty-six. It is a dated set of conservative rules, not a live copy of every commerce specification. Because protocols change, compare important launch decisions with current primary documentation.
Step 4
The first box accepts discovery J-S-O-N. The second accepts an X-M-L feed containing item or entry elements, or a tab-separated feed with a header row. You can supply either section or both. The expected feed U-R-L and merchant identity are optional comparison values. If one side of a comparison is missing, the tool says not evaluated instead of guessing that the values match or conflict.
Step 5
Choose the fictional discovery file, then the four-row tab-separated product feed. The discovery declares a public checkout endpoint, a feed address, and merchant Acme seven. The feed deliberately contains the same product I-D with different capitalization and one image address that begins with a slash. Those safe test problems let us see both passes and warnings.
Step 6
Next, type the feed address and merchant identity you expect to see. The merchant value matches the discovery after capitalization is normalized. The expected feed address is intentionally different from the address inside discovery, so that comparison should warn. Remember that both expectations came from us; the tool did not fetch them from the web.
Step 7
Select Validate. Everything is parsed locally in the browser. The result contains eight evaluated checks: five pass and three need review. That produces a rounded score of sixty-three. Treat this number as a quick summary, then open the evidence. The three warnings describe different problems and should not be handled as if they were one generic failure.
Step 8
The score simply compares the number of passing and warning checks. It does not say that one problem is more serious than another, and it does not count systems the tool never evaluated. Use it to notice that review is needed, not to certify the integration. The evidence below tells you what happened, why it matters, and how to verify a fix.
Step 9
The first checks say the discovery text is valid J-S-O-N and contains a recognized public endpoint field. That is all these passes mean. The tool has not visited the address, proved who owns it, signed in, checked security, or completed a purchase. Read a pass as evidence for the exact statement beside it, not as a pass for the entire integration.
Step 10
Here, discovery names a feed on shop dot example dot com, but our expected value names a different feed on feeds dot example dot net. The merchant identities match, so the warning is specifically about the feed address. Ask which address is the released source of truth, update the incorrect value, and run the same comparison again.
Step 11
The required-fields check passes because an I-D, title, price, availability value, and link appear somewhere in the four sampled rows. This does not mean every product row contains every field. Think of it as a sample-level presence check. Use a platform or row-level validator when each individual product must meet a stricter contract.
Step 12
Rows one and two contain S-K-U one with different capitalization. The validator normalizes capitalization, so it treats them as the same product I-D and warns. Check whether one row is an accidental duplicate, whether the variants need different I-Ds, or whether they should share a separate item-group identifier.
Step 13
The fourth row uses an image address that begins with slash images. That is a relative path, so another system would not know which website to request. The feed check requires a complete H-T-T-P or H-T-T-P-S address. It only checks the address shape; it does not download the image or verify its status, dimensions, content, or policy compliance.
Step 14
The evidence confirms that four rows were sampled and the file was recognized as tab-separated data. X-M-L support covers a small set of item and entry tags. A T-S-V needs tabs and a header, ordinary comma-separated files are not supported, and the tool stops after two hundred rows. A clean sample does not prove that every row in a larger feed is clean.
Step 15
Choose Download result card to save a compact P-N-G summary. This capture verifies that the downloaded file is a real P-N-G. Copy share link can preserve the supplied state in the page address, and the handoff links lead to separate Product schema and crawler-access checks. Review sensitive input before sharing either artifact.
Step 16
The second part of the page compares product truth. Paste the fictional facts collected from the visible page, structured data, feed, selected variant, and cart. They describe one blue shoe journey, but we deliberately changed its page address, S-K-U, and price in a few places. The comparator reads only this supplied J-S-O-N and does not request the storefront.
Step 17
Select Compare product truth. The main verdict says the supplied sources do not describe the same product. Instead of hiding the details behind a score, the table keeps each comparable field, its source values, and the reason for the decision visible. That makes it easier to assign the right fix to the page, schema, feed, or cart owner.
Step 18
Three differences explain the mismatch. Structured data drops the selected blue size-ten variant from the page address. The cart changes the S-K-U from S-K-U one to S-K-U red one. The feed says one hundred nine dollars while every other source says ninety-nine. Currency, availability, and color agree. Fields with fewer than two values remain not evaluated instead of being guessed.
Step 19
The method is deliberately small and repeatable. It parses recognized discovery fields, compares identities only when both values exist, reads a bounded feed sample, and compares supplied product facts. It does not fetch a U-R-L, validate Product schema, apply a platform policy, or test a signed-in transaction. Those live checks belong in the follow-up workflow.
Step 20
Remember the boundaries: required values can be spread across different rows, equal identity text does not prove ownership, X-M-L support is intentionally limited, and the baseline gets older. Fix the local evidence and rerun it. Then verify the live endpoint, Product and Offer schema, crawler access, currency and availability rules, account policy, authentication, cart, payment, tax, shipping, and the complete order lifecycle.
Offline readiness is a useful gate—not commerce certification.
Fix the feed address, duplicate product IDs, relative image address, and conflicting product facts shown in the evidence. Rerun the same files, then test the live endpoint, Product and Offer schema, crawler access, account rules, cart, payment, shipping, and order flow in the systems that can actually prove those behaviors.
Common issues & how to fix them
- Error Commerce discovery file is invalid Fix: Publish valid JSON at the discovery location and declare a public checkout or discovery endpoint in the supported field.
- Error Product feed item lacks a stable identifier Fix: Give every feed item a stable, unique product identifier that remains unchanged across feed refreshes.
- Error Product title is missing Fix: Add a nonempty, product-specific title to every feed item rather than relying on a category or brand alone.
- Error Product price is missing or invalid Fix: Supply a numeric product price in the feed’s expected format and pair it with a valid currency when required.
- Error Product availability is missing or invalid Fix: Map each item to a supported availability value and keep it synchronized with the purchasable product page.
- Error Product URL is missing or invalid Fix: Add a fully qualified, reachable canonical product URL for every feed item.
- Warning Product image URL is missing or invalid Fix: Supply an absolute HTTP(S) product image URL for every affected feed row.
- Error Product identifier is duplicated Fix: Give every product row one unique stable ID and merge or remove duplicate records.
- Warning Discovery feed location conflicts with the expected feed Fix: Update the discovery feed URL or the expected merchant feed location so both values identify the same canonical feed, then validate again.