Reliability
- Timeout — each delivery attempt waits up to 10 seconds for a response from your endpoint.
- Retries — on failure, the platform makes up to 3 immediate retries. After those are exhausted, there is no later automatic redelivery.
- At-least-once — every event is sent at least once, but duplicates are possible (reprocessing scenarios, for example). Handle deliveries idempotently — for example, use
orderId+eventto identify deliveries you already processed. - No ordering guarantee — different events of the same order (a purchase approval followed by a status update, for example) can arrive out of order. Don’t build your integration assuming a fixed sequence; use the payload itself (
status,updatedAt) to determine the latest state. - Exact URL — the registered URL is called exactly as it is, with no placeholder substitution (like
{some_value}).
Delivery logs
Each endpoint has its own View Logs screen with the delivery history: Sent At (date/time of the send), Event (event type delivered), Status (success or failure), Code (status of the delivery attempt), and Details (error message or the payload sent). Use it to diagnose delivery failures on your endpoint.Troubleshooting
My parser fails — it expects an object, not an array
My parser fails — it expects an object, not an array
The body always arrives as
[ { "event": ..., "body": ... } ]. Adjust your parser to read the first (and only) element of the array.Deliveries to my endpoint keep failing or timing out
Deliveries to my endpoint keep failing or timing out
Your endpoint has up to 10 seconds to respond. Return a 2xx immediately and do the heavy processing asynchronously.
Events arrive out of order
Events arrive out of order
That’s expected — there is no ordering guarantee between events of the same order. Use
status and updatedAt from the payload to determine the most recent state.My custom query parameter doesn't come back
My custom query parameter doesn't come back
Only
src, sck, and the utm_* keys are returned in trackingParameters. Send your identifiers in those fields. The exception is Abandoned cart, which returns the full query string in searchParams.Placeholders in my URL aren't replaced
Placeholders in my URL aren't replaced
The registered URL is called exactly as it is — segments like
{some_value} are never substituted. Put dynamic values in your own systems, not in the URL.FAQ
Does my tracker's click id arrive as a query param or in the body?
Does my tracker's click id arrive as a query param or in the body?
In the body. The registered URL is called as-is, with no parameters added, and there is no
click_id field in the payload. Tracking parameters captured on the checkout link return in the trackingParameters object, under the fixed keys src, sck, utm_source, utm_campaign, utm_medium, utm_content, and utm_term. If your tracker sends the click id in utm_term (a common pattern on other platforms), it returns in body.trackingParameters.utm_term on every event; src and sck work the same way. Parameters outside those keys don’t return in the payload.Can I register more than one endpoint?
Can I register more than one endpoint?
Yes. Register as many endpoints as you need, each with its own name, URL, enabled events, and product scope.
What happens if my endpoint is down?
What happens if my endpoint is down?
The platform attempts delivery immediately, with up to 3 retries on failure, but there is no later automatic redelivery after those attempts are exhausted. Track failures on the endpoint’s delivery logs screen.