--- title: Nosto CAPI slug: nosto-capi docTags: createdAt: 2026-09-15T14:46:59.442Z --- Nosto is an onsite personalization engine: it learns from what shoppers browse and buy, then renders product recommendations into your pages. This destination sends that behaviour to Nosto server-side, over Nosto's GraphQL API — unaffected by ad blockers, and able to report an order even when checkout happens on a domain your storefront does not control. # Getting Started You need a Nosto **Apps token**, created in Nosto under **Settings > Authentication Tokens**. The token is scoped to one Nosto account. If you also use the [Nosto Tag](#) destination, the token must come from the **same account** as the Account ID configured there — that is what lets both write to a single visitor session instead of two. # Connecting to the Nosto CDP Destination 1. In Chord, add the **Nosto** destination. 2. Enter your **API Token**. 3. Connect it to your back-end site. Read the deduplication note below before connecting it alongside the Nosto Tag. # Using Alongside the Nosto Tag Destination The [Nosto Tag](#) destination does the same job in the browser, and also renders Nosto's recommendations. The two are designed to run together: the tag establishes Nosto's visitor session, Chord forwards that session identifier, and this destination updates **the same** session rather than creating a second one. Browsing, cart and identity updates are safe to send from both — writing the same cart twice leaves one cart. **Orders are the exception. Do not report them from both.** Nosto publishes no deduplication rule for order submission — no dedup key, and no documented behaviour when the same order arrives twice — so running both destinations reports each order twice. Choose one surface for orders. This one is the more reliable of the two; the tag is the more like-for-like if you are replacing an existing Nosto installation. **Without the tag**, this destination still reports orders, identifying the customer by your own customer reference. It cannot contribute browsing behaviour, because there is no browser session for it to attach to. # Deduplication Chord sends your order's own reference as the order `ref`, so that is the value to deduplicate against if another system also sends orders to Nosto. Nosto does not document its behaviour on a repeat submission, so treat "send each order once" as the rule. # Event Mapping | Chord event | Nosto mutation | | ------------------------------------------------------ | ------------------------------------------------------------ | | `Page Viewed` (home page) | Session update — front page view | | `Page Viewed` (any other page) | Not sent — the specific view event covers it | | `Product Viewed` | Session update — product view | | `Product List Viewed` | Session update — category view | | `Products Searched` | Session update — search | | `Cart Viewed` | Session update — cart page view | | `Product Added`, `Product Removed`, `Checkout Started` | Session update — cart contents, without counting a page view | | `identify`, `Signed Up`, `Email Captured` | Session update — customer details | | `Order Completed` | Order placement, with line items | | `Order Refunded` | Order status update | **One view is recorded per navigation.** Your storefront fires `Page Viewed` *and* a specific event like `Product Viewed` on the same page load, and recording both would report every product page to Nosto twice. The specific event records the view; the generic `Page Viewed` carries nothing else Nosto can store, so no call is made at all. The home page is the exception — it has no specific event of its own, so there `Page Viewed` records the front-page view. This matches the Nosto Tag destination exactly, so running both does not reintroduce the double count for views. Browsing and cart events need the visitor's Nosto session, so they are only sent when the Nosto Tag is also running and has established one. Orders do not. # Order Values Line items send the product ID, variant ID, name, unit price, quantity and currency. Values are sent as decimal amounts in the order's own currency — a $22.43 line is sent as `22.43`, not in cents. Currency is sent when your event carries one and omitted otherwise, so Nosto applies your account's default rather than Chord guessing. Order status and payment provider are likewise sent only when your event includes them. # Identity Nosto receives email address, first and last name, and your customer reference **in plaintext**, deliberately. Nosto resolves a shopper to a stored profile and addresses them by name in the experiences it renders, so unlike an advertising API it accepts no hashed identifier — hashing would break the product rather than protect it. If your security review needs to know exactly what is transmitted, that is the list. Marketing permission is sent only when your event carries one; Chord assumes no default. # Gotchas **Refunds are this destination's job.** Nosto exposes order-status transitions only through its GraphQL API, so the Nosto Tag cannot report them. If refunds matter to your reporting, this destination is the only way to send them. **Emptying a cart does not clear it in Nosto.** Chord's `Product Removed` carries the removed line, not the cart that remains, so Chord cannot distinguish "the cart is now empty" from "this event had no products". Rather than risk clearing real carts, Nosto's cart is left alone in that case and updates on the next cart-bearing event. **Nosto's event set is fixed.** There is no arbitrary custom event. Chord events with no Nosto equivalent are not sent, and the reason is recorded in the destination's logs. **Sessions expire after 30 minutes** of inactivity. An event arriving after that has no live session to update; orders are unaffected, since they identify the customer directly. **Consent gating applies.** Nosto's session cookie is only set after consent, so before a visitor consents there is no session for this destination to update. Orders identified by customer reference are unaffected. **Updated 1 September 2026**