Tracking & Server-Side Events
Tracking keys, the installer payloads, and the two ways a system posts an outcome it already knows about.
Two different jobs live here. Tracking keys and installers are how the
browser tracker gets onto a site. POST /api/v1/events is how a system that
already knows an outcome happened — an ERP, a POS, a back office — tells Atribu
without a browser at all.
Tracking keys
POST /api/v1/tracking/keys
GET /api/v1/tracking/keysThe POST is idempotent by natural key: a profile that already has an
active key gets that key back rather than a second one. So an agent can call it
unconditionally on every run without accumulating keys.
Installer payloads
GET /api/v1/tracking/snippet
GET /api/v1/tracking/installers/gtm
GET /api/v1/tracking/installers/shopify-pixelsnippet returns the raw <script> (optionally bundled with the Meta Pixel);
the two installers return the payload a Google Tag Manager container or a
Shopify Web Pixel expects. An agent that can edit the site puts the snippet in;
one that cannot hands the payload to the person who can.
The by-hand versions of all three, with screenshots, are in Install the tracker.
Server-side outcome events
POST /api/v1/eventsThis is how a dealer's ERP posts a closed sale. Two rules matter more than the schema:
The idempotency key is required whenever the event carries money
Without one it defaults to a fresh UUID, and a retried sale becomes a second conversion. A payment posted twice is revenue counted twice, and every ROAS on the profile is wrong afterwards.
event_type is free text. What gives a name meaning is a
conversion definition that lists it — there is no fixed
sale_closed type to look up. Post checkout_completed and then define what it
means; the definition is what decides whether it counts as cash, and whether it
is attribution-eligible.
POST /api/v1/payments/webpay is the same idea for Transbank Webpay, which has
no OAuth connection to authorize: the payment is reported directly. See
Webpay.
A CRM connection is not required
Readiness's crm_or_outcome_source_connected step is
satisfied by outcome events arriving on this route. A system that posts its own
outcomes needs no CRM and no browser.
| Method | Path | What it does |
|---|---|---|
POST | /api/v1/events | Ingest a server-side outcome event (e.g. a closed sale) |
POST | /api/v1/payments/webpay | Report a Webpay (Transbank) payment |
GET | /api/v1/tracking/installers/gtm | Get the Google Tag Manager installer payload |
GET | /api/v1/tracking/installers/shopify-pixel | Get the Shopify Web Pixel installer payload |
GET | /api/v1/tracking/keys | List the profile's active tracking keys |
POST | /api/v1/tracking/keys | Issue a tracking key (idempotent) |
GET | /api/v1/tracking/snippet | Get the raw tracker snippet (with optional Meta Pixel bundle) |
Generated from openapi.json. The full request and response schema for every operation is in the OpenAPI document.