Give your catalog a key it can compare

A marketplace title reads “Samsung Galaxy S24 Ultra 256GB Titanium Black.” Another seller changes the word order or writes the storage as “256 GB.” Your price comparison agent needs a way to find candidate matches without treating every title variation as a separate product.

sku-normalize turns a raw title into named product attributes, with a canonical key for grouping records. Each response also includes a confidence value so your workflow can decide which results need review.

The endpoint costs 0.01 USDC per call, paid through x402 on Base mainnet. Route a request here when an agent has a product title and needs fields it can compare against an existing catalog.

Keep the original listing. You'll need it when a shortened title leaves out a detail that matters to the purchase.

Send the title with a category hint

Send JSON to POST https://x402.agentutility.ai/sku-normalize. The required title accepts up to 500 characters; sku is an accepted alias. An optional category string gives the parser context.

Here's a request body for a smartphone listing: 

{
  "title": "Samsung Galaxy S24 Ultra 256GB Titanium Black",
  "category": "smartphones"
}

Use that body in your x402-capable HTTP client. Payment is part of the request flow, so a plain HTTP client needs payment handling before it can complete a paid call.

The following is an illustrative response excerpt showing the product fields. It's an example of the output shape, not a recorded response for this request: 

{
  "title": "Samsung Galaxy S24 Ultra 256GB Titanium Black",
  "category": "smartphones",
  "brand": "Samsung",
  "model": "Galaxy S24 Ultra",
  "variant": "Ultra",
  "capacity": "256GB",
  "color": "Titanium Black",
  "canonical_key": "samsung-galaxy-s24-ultra-256gb-titanium-black",
  "confidence": 0.92
}

Now your importer has a storage value it can compare directly. It can also group the record under a proposed product key without making the seller's original wording your database identifier.

A category hint helps interpret ambiguous text. It doesn't supply missing specifications. Fields that can't be determined are represented as null, and the canonical key can be null if nothing can be determined.

Use the key to find candidate matches

The canonical key is a lowercase, hyphen-joined representation of the extracted attributes, with missing values omitted. Store the returned key alongside the source record.

That makes a useful first pass for duplicate detection. Records with the same key can enter the same candidate group, where your matching rules compare the details that define a sellable item.

But a matching key doesn't establish that two offers are interchangeable. A title can omit condition, and the listed output fields don't include a dedicated condition field. A refurbished phone and a new phone therefore need checks beyond this response before your agent combines their prices.

Capacity deserves an explicit check too. A 256GB listing and a 512GB listing belong to different product variants even if the rest of their titles match.

And keep merchant identifiers separate from canonical_key. Your source listing ID remains useful when a merchant changes its title or your catalog revises a match.

Let confidence control the next step

confidence is a number from 0 to 1 describing confidence in the parse. A value of 0.92 doesn't establish a 92% probability that two listings represent the same sellable item.

Set your acceptance threshold using reviewed examples from your own catalog. For phones, require the attributes your matching policy needs before allowing an automatic join. A high score with missing capacity still leaves your storage comparison unresolved.

So give incomplete records a review path. Preserve their extracted fields and keep them out of automatic merges until the missing evidence arrives.

For request validation, send a nonempty title within the 500-character limit. Missing or oversized titles return HTTP 400. Check the HTTP status before reading product fields, and keep failed requests out of the matching table.

At the listed rate, 1,000 calls cost 10 USDC in endpoint charges. Deduplicate identical title-and-category inputs before submitting a feed, then reuse saved results for unchanged rows on the next import.