fetch.
The runtime loads automatically. Nothing to install.
Why not watch network calls
A response code does not tell you what happened.GET /cart answers 200 on
every page load. The event that matters most, a completed payment, does not
happen in the browser at all. URLs also carry personal data in query strings,
and patching fetch breaks when another library wraps it first.
The bus emits what happened, with identifiers only.
The API
window.SalesiveEvents exposes:
If your script loads before the runtime
Queue your handlers. The runtime drains and clears the queue when it starts.Event shape
source is sdk, theme, network or app. Payloads contain identifiers
only. No email, phone number, address, token or cart contents are ever included.
Events
The search event carries the query text, trimmed and capped at 120 characters.
It is the only event allowed to carry free text. Treat it as shopper data:
someone can type anything into a search box, including an email address or a
phone number, so keep it only as long as your app needs it and never use it as
an identifier.
category:viewed and blog:post_viewed are emitted by the theme, since no API
call happens when a shopper opens a category or a post. cart:coupon_removed
is defined for completeness; the store API has no coupon removal route yet, so
it does not fire today.
Network fallback
Pages that do not use the Salesive SDK emit fewer events.observeNetwork()
turns on a fallback that watches fetch and XMLHttpRequest and maps a small,
platform maintained route table to the same event names.
Events are not the record of truth
Use client events for user experience, attribution and analytics. Use webhooks for anything that must be correct:orders/paid
from your app’s server is the authoritative signal that a payment completed. A
browser event can be lost to a reload, a blocked script or a closed tab.

