Record a storefront analytics event
Records a first-party storefront analytics event — a page view or the start of a browsing session. These events power Store Analytics: traffic, audience, the conversion funnel, and revenue-by-source reporting that the merchant views in their dashboard.
Fire this from the storefront on each route change. Send session_start for the
first event of a new browsing session and page_view for each page thereafter.
Provide a stable visitor_id (persisted in the browser, e.g. localStorage) so
returning visitors are recognised, and a session_id per browsing session (the
same identifier you use for an anonymous cart) so events group into a session.
The device, browser, operating system, and approximate location (country/region)
are derived automatically from the request — you do not send them. Pass only the
path (the pathname; query strings are ignored), the referrer, and any UTM
campaign parameters present on the landing URL. Publishable keys are accepted, so
the call can be made directly from the browser. The request is processed
best-effort and returns immediately; it never blocks the page.
Authorizations
API Key Authentication
Use your API key in the Authorization header:
Key Types:
Secret Keys (Server-Side Only):
- Format:
tybrite_sk_live_*(production) ortybrite_sk_test_*(sandbox) - Full read/write access to all endpoints
- ⚠️ NEVER expose in client-side code or public repositories
- Required for: write operations, authentication, payment verification, AI recommendations
Publishable Keys (Client-Safe):
- Format:
tybrite_pk_live_*(production) ortybrite_pk_test_*(sandbox) - Read-only access (GET requests only, plus POST semantic search)
- ✅ Safe for client-side JavaScript, mobile apps, and public code
- Allowed for: browsing products, search, CMS content, pricing queries
Endpoint-Specific Requirements:
- Authentication endpoints (
/v1/auth/*): Secret key required - Payment verification (
POST /v1/payments/verify): Secret key required - AI Recommendations (
POST /v1/recommendations): Secret key required - Semantic Search (
POST /v1/search): Both key types allowed (read-only operation) - All write operations: Secret key required
- All read operations: Both key types allowed
Using a publishable key for restricted operations returns 403 Forbidden.
Body
session_start for the first event of a session, page_view on each route
change, and page_close (with duration_ms) fired on page hide to capture
dwell time — send it with navigator.sendBeacon from a visibilitychange /
pagehide handler so it survives the page unload.
For the CMS conversion funnel: post_view / lookbook_view when a shopper opens
a blog post / shoppable lookbook (send content_id), and content_click when
they click through to a product from inside that content (send content_id +
content_product_id). To close the funnel, pass content_id (+ content_type)
in the order's attribution at checkout — see the Orders API.
search records what a shopper searched for. Send it with search_query and the
search_result_count the search returned, so a merchant can see which searches
their catalogue answers badly. The term is normalised before it is stored, and a
search event is never associated with a customer.
search_result_click records which result the shopper clicked. Send it with the
same search_query, the search_result_product_id they clicked, and its
search_result_position in the list as shown. This is what makes merchandising
measurable: without it, a rule can only be judged by whether searches matching it
happened to convert, which counts a shopper who ignored the featured product
exactly the same as one who clicked it.
page_view, session_start, page_close, post_view, lookbook_view, content_click, search, search_result_click A stable per-visitor identifier persisted in the browser (e.g. localStorage). Used to distinguish new vs returning visitors.
The shopper's browsing-session identifier (same concept as the anonymous cart session). May also be sent as the x-session-id header.
The shopper's search term. Required when event_type is search, ignored
otherwise. Leading, trailing and repeated whitespace is collapsed and the term is
lowercased before storage, so casing and spacing do not fragment the reporting.
May also be sent as q.
200Alias for search_query. Accepted so a storefront can reuse the same field name it
sends to the search endpoint; search_query takes precedence when both are given.
200The product the shopper clicked. Required when event_type is
search_result_click — a click with no product cannot be attributed to anything.
Its 1-based position in the results as they were shown. Optional, but worth sending: it is what distinguishes a product that was clicked because it was featured from one that would have been found anyway.
x >= 1How many results the search returned. Send 0 when it returned none — that is the
signal a merchant most needs, marking a search the catalogue could not answer at
all. Only meaningful when event_type is search.
x >= 0The page path being viewed. Only the pathname is stored; any query string is discarded.
The document referrer, when present.
Time spent on the page in milliseconds. Send with a page_close event to power average time-on-page and session-duration metrics.
The signed-in shopper, when known.
For post_view / lookbook_view / content_click — the CMS post or lookbook id. (Also accepted as cms_content_id.)
Alias of content_id. Send one or the other, not both.
For content_click — the product the shopper clicked through to from inside the content. Required (with content_id) on a content_click.
Response
The event was accepted.

