ActessiaBook a 30-day pilot
Documentation

The catalog: feed, endpoint, or your pricing page

Where recommendations come from. Structured attributes, offers with real prices, and the rule that the agent never states a price the catalog did not give it.

Recommendations need structured attributes (price, tier, prerequisites, exclusions, entitlements), which crawled HTML is bad at. Three tiers, from best to easiest:

  1. Catalog endpoint: a JSON endpoint on your side that we poll. Highest fidelity.
  2. Feed upload: a scheduled CSV or JSON file. Where most customers live.
  3. Crawl + structured extraction: JSON-LD Product markup on your pricing page first; an LLM extraction as fallback, flagged as lower confidence on the dashboard.

A more precise tier always wins: a crawl never overwrites a feed row.

Feed format

JSON: {"products": [ … ]}. Each product: external_id (the upsert key), name, description, category (plan, addon, module, seat_pack…), url, attributes (a scalar map: true/false = included or not, a number = a limit, null = unlimited), prerequisites, exclusions, entitlement_keys, tags, weight (0..1), active, and offers[], each with name, price_cents, currency, billing_period (one_time, monthly, annual, usage), optional tier, valid_from, valid_to.

At least one offer is required: a product without a price is never recommended, because the agent could not state one.

CSV: the same fields as columns, one row per offer (product columns repeat). Per-row errors are reported and never abort the rest.

JSON-LD on your pricing page

<script type="application/ld+json"> with Product (also IndividualProduct, ProductModel, Service), inside @graph, ItemList or hasOfferCatalog. sku, productID or @id become the id; additionalProperty → attributes; Offer / AggregateOffer with price and priceCurrency → offers. The billing period is read from billingDuration, unitCode or the words in the offer name, never guessed: without evidence it is one_time.

The rule

The agent phrases what the catalog returns. It never selects a product on its own, never invents a price, and never mentions our plans: when a user needs more than their plan of your product allows, it recommends your upgrade.