Skip to content

Conversions API

Send conversions from your backend, independently of the pixel (ad blockers, purchases validated outside the browser, delayed payments). The conversion is attached to the visitor’s most recent session within the site’s attribution window, then goes through the same attribution pipeline as pixel events.

The full machine-readable contract is available in the API reference (OpenAPI).

POST /api/sites/:siteId/conversions
  • siteId: the site’s UUID (visible in the dashboard) — not the tracker identifier.
Authorization: Bearer ask_xxxxxxxxxxxxxxxx

API keys are created in the dashboard: Settings → API Keys. They are tenant-scoped: the targeted site must belong to the key’s tenant (otherwise 403). Keys start with ask_ and are stored hashed (they cannot be displayed again — save them at creation).

Content-Type: application/json

Field Type Required Description
clientId string one of the three¹ The user id passed to identify() on the pixel side — recommended join key
visitorId string one of the three¹ Value of the _astr_vid cookie (fallback)
sessionId string one of the three¹ Session id (fallback)
orderId string required when type = "purchase" Order id, unique per site. Deduplication key against pixel events: the same order sent by the pixel and by your backend is counted once
type string no Conversion type, default "purchase"
value number no Amount, ≥ 0
currency string no ISO 4217, default "USD"
occurredAt string no ISO 8601, default: now (the order validation time)

¹ At least one of the three identifiers (clientId, visitorId, sessionId) is required to resolve the session.

Terminal window
curl -X POST "https://tracker.adstrike.io/api/sites/9b2f1c3a-....-....-....-............/conversions" \
-H "Authorization: Bearer ask_xxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{
"clientId": "USER_12345",
"orderId": "ORDER-10042",
"type": "purchase",
"value": 129.5,
"currency": "EUR",
"occurredAt": "2026-07-22T10:32:00Z"
}'
Code Meaning Body
202 Conversion accepted and queued { "success": true, "sessionId": "...", "eventId": "..." }
400 Validation error (missing/invalid field) { "error": "..." }
401 Missing or invalid API key { "error": "..." }
403 The site does not belong to the key’s tenant { "error": "..." }
404 Unknown site { "error": "..." }
422 No session resolvable from the provided identifiers (unknown visitor, or outside the attribution window) { "error": "..." }
503 Queue unavailable — retry (exponential backoff recommended) { "error": "..." }

202 means “accepted and queued”: processing (attribution, currency conversion) is asynchronous.

  • Call the API when the order is validated, not at checkout. A conversion sent at confirmed/validated payment time guarantees cancelled or failed orders are never counted.

  • Always send orderId + clientId. orderId makes the call idempotent (safe retries, dedup with the pixel); clientId is the most reliable join key, including cross-device.

  • Keep the pixel purchase event active. The two sources are complementary: the pixel covers browser-side real time, your backend covers cases where the pixel is blocked. The orderId/tid deduplication makes the whole idempotent — same order = one conversion.

  • Maximize identify() coverage. The earlier identify() is called on the website (through the pre-init queue), the more reliable session resolution by clientId becomes:

    (window.adstrikeQ = window.adstrikeQ || []).push(["identify", "USER_12345"]);

    See Tracker.

  • Handle 422 with ONE delayed retry for fresh orders. Right after a purchase, the pixel batch creating the session may still be in flight — retry once after 1–2 minutes. If it persists, treat it as permanent (the user never visited the site with the pixel active); only 503 warrants backoff retries.