Skip to main content
Whatmore keeps its own copy of your product data (title, price, image, availability) so videos can be made shoppable. You keep that copy in sync two ways:
  • Pull — how products get in (primary): connect your product API once in the dashboard and add your product URLs. Whatmore reads each product from your API and stores it — for the initial load, for every new product you add, and on refresh. This is all most integrations need.
  • Push — real-time updates (optional): when price or availability changes, push the change via API so tagged products update immediately, without waiting for a refresh.
Video upload and product tagging happen in the Whatmore dashboard.
Video & media are managed in the dashboard — there is no upload API to integrate. Your only catalog job is exposing a product API Whatmore can read (pull); the real-time push is optional. Less to build on your side, faster go-live.

Pull: initial load and refresh

You add products by their URL — there’s no product-creation API to call. In dashboard.whatmore.live you connect your product API (an endpoint that returns a single product’s detail, plus any auth it needs) and add your product page URLs. For each URL, Whatmore extracts the product id, calls your product API for that product, and stores the returned JSON. This is how the initial load, every new product, and each refresh work.

How the product id is read from a URL

Whatmore turns each product URL into a product id — the value it uses to query your API, and which it stores as your client_product_id.
  • Give us a regex to extract it exactly (recommended). For a Nike-style URL https://www.nike.com/t/air-max-90-shoes/CN8490-002, a rule such as ([^/]+)$ (the last path segment) yields CN8490-002. A regex keeps extraction deterministic across all your URL shapes.
  • Default behaviour today: with no rule set, Whatmore takes the trailing token of the URL — it splits on - and uses the last segment. That works when the URL ends in the id, but is brittle for other URL patterns, so providing a regex is strongly recommended.

Expected product JSON

Your product API returns a single product’s detail as JSON. The shape is flexible — you map fields to Whatmore’s in the dashboard, and nested keys are supported (expand the tree view to pick them). A representative response:
Every field, its type, and where it maps in Whatmore: Field names above are illustrative — your API can use any names, and you map them in the dashboard (nested keys included). Only the id, title, price, product URL, and first image are strictly required; the rest are recommended or optional. See your platform guide for the exact endpoint and credentials: WooCommerce · Custom / headless · Magento · SFCC · BigCommerce.

Product identity

  • client_product_idyour product id, extracted from the product URL (see above) and normally identical to the id your API returns. It is the key you reuse on every push and in order tracking: whatever value ends up here must be the exact same value you send in order_items[].product_id, or the item can’t be attributed.
  • product_link — the product’s URL.
  • Whatmore also assigns its own internal numeric product_id for its records.

Push: real-time updates

New products flow in through the pull above. Push is optional — use it only when you want a price or availability change to reflect immediately, without waiting for the next refresh. It uses a bearer token; the base URL is https://api.whatmore.live. Status codes and response conventions are on Errors & Conventions. POST /v2/product upserts a product by client_product_id — creating it if it’s new and updating it otherwise. The body is the product in Whatmore’s field names, mirroring the product JSON above:
On update, only the fields you send are changed — omit the rest. New products still flow in automatically through the pull; use POST /v2/product only when you need an immediate update.