Your Endpoint
We send each tracked event to your own endpoint, server-to-server, as it is processed. You provide the URL; there is no third-party platform to configure.
It is the mirror image of Webhooks: there, your systems send events to us; here, we send the finished event back to you — already merged across browser and webhook routes, with identity resolved, attribution computed and values normalised.
When you would use it
You already have a system that should know what happens on the site — a CRM, a data warehouse, a lead scoring service, an internal dashboard. Instead of querying us, you receive each event as it happens, in a shape that stays the same regardless of which e-commerce platform the shop runs on.
Typical uses: feeding a warehouse, matching leads against an internal customer base, triggering a workflow on a purchase, or keeping an order table in sync with cancellations.
Transport
| Method | POST |
| Content-Type | application/json |
| Endpoint | yours — any HTTPS URL you provide |
| Authentication | one static header — you choose the name and the secret value, we send exactly that on every request |
| Timeout | 5 seconds |
| Retries | none |
Authentication is the header and nothing more. We do not sign the body, do not send a timestamp, and there is no token to exchange or refresh — so HMAC verification, replay windows or an OAuth flow would have no input to work with. Compare the header in constant time, keep the secret out of your code, and serve over HTTPS.
Requests arrive with User-Agent: DataReshapeStream/1.0. If a WAF or bot protection sits in front of your endpoint, allow-list it — a blocked request is a lost event, not a retried one.
Delivery is best effort: we send once and do not retry. If your endpoint is down or slow, that event is not redelivered. Two consequences worth designing for:
Acknowledge fast. Return 2xx as soon as you have the payload and process it asynchronously — the 5 second timeout covers the whole round trip, not just your first byte.
Treat gaps as normal. If your system must be complete, reconcile periodically against your own source of truth rather than assuming the stream never misses anything.
Duplicates and idempotency
The same event may arrive more than once — for example when an order is seen both by the browser and by the shop platform's webhook. Use the identifiers to deduplicate on your side:
event.deduplication_id is present on every event and is the general-purpose idempotency key.
event.unique_id is the identifier from the source platform — the order number, the lead id. It is present on orders and leads, empty elsewhere. Use it when you need to correlate with a record you already hold, such as applying a cancellation to the order it belongs to.
What the payload guarantees
The key list is fixed. The same keys arrive on every event, in the same shape, whatever platform the shop runs. A new key appears only through an announced change — see the Changelog.
Declared keys are always present. Inside event, user, attribution, context, consent and values, a key that does not apply arrives empty ("", 0, [], {}, or null) rather than missing. You can read them without existence checks.
The exception is the order lines — products, coupons, shipping, payments — where a few keys may be absent entirely. Those are marked as such in the reference.
Personal data leaves only as fingerprints. Email addresses, phone numbers and names are sent as SHA-256 hashes of the normalised value. Plain values never leave our system.
Consent decides what is in the payload. A visitor grants consent per category. Anything that depends on a category they declined may be absent, empty, or anonymised, and what is restricted can widen over time as privacy rules and platform requirements change. Build for that from the start rather than assuming today's payload is the maximum you will ever get.
The consent container arrives on every event and states what the visitor granted, so an empty identifier is explainable rather than mysterious: read the consent state before concluding that data is missing.
Two things follow for a receiver:
An empty identifier is a normal, legitimate event — not a validation error, and not a different person. Do not reject the event and do not create a second record.
The same visitor can produce events with different levels of detail over time, because consent can change. Design the store to enrich a record when more arrives, rather than assuming the first version was complete.
Building the receiver with an AI assistant
If you use an AI assistant while integrating, give it prompt-your-endpoint.txt as context. It covers the handler shape, idempotency, ordering, matching people on hashes, and the mistakes receivers make most often — and it points the assistant at the reference below rather than letting it guess field names.
Every page here also exists as Markdown: append .md to the path, for example payload.md.
Next
The Payload Reference documents every container and key, with types and examples.
The Changelog lists dated changes, and explains which kinds of change we announce in advance and which can appear at any time.