API Reference

Every endpoint behind Smler attribution: the browser SDK, the track lead and track sale conversion API, and how attribution methods are scored.

September 2, 2026 5 min read

Abhishek Singh

Published in Smler Docs

Everything here sits underneath the snippet and the two calls covered in the Developer Quickstart. Most integrations only ever need those two: the snippet, and the server side sale event. This page is for anyone who needs the raw HTTP behind them, or the full conversion API.

Core ids

Site key (sm_pk_...), public, identifies your domain to the tracking endpoints. Safe to expose in client side code.
Visitor id (sm_vid cookie), a first party id for the browser, minted on first contact.
Touch id (sm_id cookie, also called smid), identifies one specific click. This is the id you forward as smid when reporting a sale.
API key (the x-code header), private, authenticates the server side conversion API. Never expose this in browser code.

Browser SDK, served from sm.js

All public, unauthenticated beyond the site key, and rate limited per site key and IP. Called automatically by the snippet, you do not normally call these directly.

Endpoint	What it does
`GET /api/v2/attribution/sm.js?key=`	Serves the tracking script itself, already configured for your site key.
`POST /api/v2/attribution/collect`	Called on every page load. Binds the attribution id to the visitor and sets first party cookies where possible.
`POST /api/v2/attribution/identify`	What `sm.identify()` calls. Attaches a hashed email or external id to the current visitor.
`POST /api/v2/attribution/event`	Records a named browser side lead event, for example a signup. Sales are never sent from the browser, only from your server.
`POST /api/v2/attribution/lookup`	Returns the current attribution (touch id, creator, campaign, UTM values) for this browser. Used internally by the SDK and the setup checklist.

Server side conversion API

Authenticated with your API key in the x-code header. This is what you or a connected store call when something worth crediting happens.

POST /api/v2/conversion/track/sale

Field	Required	Notes
`customerExternalId`	Yes	Your own user id for the customer.
`amount`	Yes	In the smallest currency unit, cents for usd.
`currency`	No	3 letter code, defaults to usd.
`smid`, `visitorId`, `domain`	No	Attribution hints, send whichever you have. Only set `domain` on a multi domain account.
`customerEmail`, `customerName`, `customerAvatar`	No	Used for identity matching and the Activity feed.
`invoiceId`, `paymentProcessor`, `eventName`, `metadata`	No	Free form record keeping. `metadata` is capped at 10,000 characters as JSON.

POST /api/v2/conversion/track/lead

Same attribution hints and identity fields as track/sale, for events before a purchase (signup, trial start, demo booked). Also takes eventName (required) and a mode of async, wait, or deferred (defaults to wait).

How a match is scored

Every conversion is matched by the strongest signal available, in this order. Only the top three count as deterministic, the rest are surfaced to you as lower confidence rather than presented as certain.

Method	Confidence	What it means
`explicit_click`	1.0	Click id sent with the conversion.
`touch_param`	0.99	Attribution id captured from the landing URL.
`visitor_cookie`	0.95	First party browser id.
`identity_external_id`	0.9	Known customer id, from an earlier identify call.
`identity_email`	0.85	Hashed email match.
`customer_history`	0.8	An earlier event from the same customer.
`probabilistic`	0.5	Device and network match, only used if enabled in Settings.

See Settings & Privacy for the attribution window and model that decide which touch wins when more than one is eligible, and the Developer Quickstart for the three calls almost every integration actually needs.

Published with LeafPad