Lifecycle (server-side)
Push the replay link into ActiveCampaign, Mailchimp, Iterable or Klaviyo from our server the moment a session gets your own customer ID.
1. Why this exists next to the browser bridge
MousePlayer already has a lifecycle bridge that writes into the SDK running on your own page - Klaviyo, Braze, Customer.io and six others. This one does the same job from our server instead, and it exists because for two of the biggest platforms the browser route is simply not available:
- ActiveCampaign has no browser API for events at all. Its
vgo()can set an account and an email address and start tracking - it cannot send an event. Events go through the Event Tracking API with a separate event key, server-side only. - Mailchimp has one, but with a closed vocabulary. Its site-tracking pixel accepts
PAGE_VIEWED,PRODUCT_VIEWED,PURCHASEDand a handful of other predefined names. There is no slot for a custom event, and pressing our data into aPAGE_VIEWEDwould be a lie inside your own data model.
For Iterable and Klaviyo the server route is simply the more reliable one: no ad blocker, no SDK that may or may not have loaded, no tab closing early.
2. What it needs
Three fields, and which of them you fill in depends on the platform.
| Platform | Account field | Key |
|---|---|---|
| ActiveCampaign | actid | Website → Site Tracking, next to the event key |
| Mailchimp | The audience ID | An API key - keep its -us14 style suffix, the data centre is read from it |
| Iterable | not needed - leave it empty | A key with the permission "Allow event track calls" |
| Klaviyo | not needed - leave it empty | A private API key |
The third field is the event name it will show up under. Keep it short: 32 characters at most. That is the limit of the API, not ours, and we shorten it when you save rather than when we send - otherwise the form would show you something different from what arrives.
Mailchimp: keep the suffix on your API key. The part after the last dash (-us14) names the data centre your account lives in, and the address is built from it. A key without it is rejected with a clear message instead of failing somewhere you cannot see.
3. When it fires - and when it does not
At the moment a session is identified: when your site calls MousePlayer.setUserId(), when our analytics bridge reads a distinct ID back, or when your server calls the identify endpoint. Before that we do not know who the recording belongs to.
Only with an email address
All four platforms address a contact by their email. If your customer ID is a contract number, nothing is sent - queueing a task that can only fail would just fill your log with noise.
The contact has to exist already. None of these platforms create one from an event; ActiveCampaign discards the event entirely if it does not recognise the address. This bridge enriches your existing contacts - it does not build your list.
Every event carries an ID
So the same session cannot be counted twice, even if a task is retried.
4. What arrives on the other side
One event, carrying the replay link as a property named mouseplayer_session_url. Open it and you are in the recording of exactly that session.
From there it is your platform's own logic: use the event as an automation trigger, as a segment condition, or simply let your team open the recording from the contact.
The key never leaves our server
It is stored AES-256-GCM encrypted, never shown again after saving, and it is deliberately not put into the internal queue that carries the task - the worker fetches it from the database itself.
HTTP 200 does not mean delivered
ActiveCampaign answers with status 200 and {"success":0} when it rejects an event. We read the response body, not just the status, so a rejection appears as a failure in the delivery log rather than as a silent success.
5. Braze, Customer.io and Brevo
Three more platforms on the server-side path. Two of them need something the others do not: a place.
| You provide | Identified by | |
|---|---|---|
| Braze | REST endpoint and API key | email address |
| Customer.io | site ID, API key and your region | your own customer ID |
| Brevo | the tracker key, nothing else | email address |
Two of them live somewhere specific
Braze runs instance-bound REST endpoints; Customer.io runs two separate regions with different hosts. Neither can be derived from the key, and picking the wrong one answers 401 - which sends you looking at the key. Both fields exist for that reason alone.
Customer.io is the one that does not need an email
It knows people under the same ID you assign them, so requiring an email address would be an invented hurdle. The other six do match on email, and for them a session identified by a contract number produces nothing - correctly.
No new profiles
The Braze call carries _update_existing_only. The same decision as the CRM bridge: a browser session is not a reliable statement about who your customers are, and a lifecycle platform that grows a profile per anonymous visitor is worse than no integration.
Brevo answers 204, Braze answers 201 with a catch
Brevo returns no body at all - there, a 2xx really is the whole truth. Braze returns "message": "success" and may carry an errors array beside it: fatal problems appear in the message, tolerated field losses only in errors. Reading either one alone gets it wrong in one direction or the other.
All trademarks named here belong to their respective owners. MousePlayer has no business relationship with these providers.