Mixpanel as a destination

Use this when survey responses should land in Mixpanel alongside your product events.

Every survey response and survey lifecycle event arrives in Mixpanel as a track call against the same distinct_id Mixpanel already knows for the user.

1. Get a Mixpanel project token

In Mixpanel, open Settings → Project Settings.
Copy the Project Token.
Note your project's region:
- US (default): https://api.mixpanel.com
- EU: https://api-eu.mixpanel.com
- India: https://api-in.mixpanel.com

2. Create the integration

Open Integrations and click New integration.
Under Data out, choose Mixpanel.
Click Continue.
On the detail page, paste the Project Token.
Pick the Destination endpoint for your project's region.
Click Save configuration.

Survey events start flowing on the next response.

Event payload

We emit three flow lifecycle events:

Event name	When it fires
`Flow Viewed`	A survey was shown to a user.
`Flow Dismissed`	The user dismissed a survey without submitting.
`Response Submitted`	The user submitted a response.

You can rename or disable each event in the Events section of the integration detail page — match your own naming convention (e.g. survey_responded), or turn off events you don't want forwarded.

Each enabled event arrives in Mixpanel as a track call:

{"event": "Response Submitted","properties": {"token": "<your project token>","distinct_id": "user_123","$insert_id": "evt_…","time": 1747130040,"response_id": "resp_…","survey_id": "srv_…","app_id": "app_…","organization_id": "org_…","traits": { "email": "user@example.com" }}}

$insert_id is set per event so Mixpanel can dedupe replays. Don't strip it in a proxy.

See Events for more on the event shape and how to send your own.

Properties we send

The Mixpanel payload has event at the top level and the rest inside properties:

Property	Always sent?	Notes
`token`	Always	The project token from your integration.
`distinct_id`	Always	The user identifier resolved by getuserfeedback.com.
`$insert_id`	Always	Stable per event. Mixpanel uses it for dedupe.
`time`	Always	Unix seconds when the event occurred.
`app_id`	Always	Your app identifier.
`organization_id`	Always	Your organization identifier.
`survey_id`	When available	The survey the event relates to.
`response_id`	When available	The response the event relates to (set on `Response Submitted`).
`traits`	When available	Profile traits known at the time, e.g. `email`.
`identities`	Always	The identifiers we resolved against.
`references`	Always	Internal references for tying the event back to other surfaces.
`page_path`	When available	Page the event happened on.
`page_referrer`	When available	Referrer at the time of the event.
`locale`	When available	Browser locale, e.g. `en-US`.

Identity

distinct_id is taken from the user's resolved userId, or anonymousId if no userId is known yet. If you also use the getuserfeedback.com widget on the same product, the same distinct_id is used everywhere, so events land on the existing Mixpanel user profile instead of creating a new one.

Delivery and retries

If Mixpanel returns a retryable error (5xx, 429, or a transient network failure), we retry the event with exponential backoff: 1 minute, 2, 4, 8, 16, 32, 64 minutes, then a final attempt up to 6 hours later. After 8 attempts an event stops retrying.

Permanent errors (4xx like an invalid Project Token) fail immediately without retries. Each event has a stable $insert_id, so Mixpanel dedupes retries within its 7-day window.

What can break

401 from Mixpanel. The Project Token is wrong or belongs to a different project. Copy it again from Mixpanel Project Settings.
No events in Live View. Wrong region. Pick the endpoint that matches your project's region — Mixpanel does not forward traffic across regions.
Integration paused. Paused integrations don't deliver. Resume from Integrations.
Events look duplicated. Mixpanel dedupes on $insert_id for seven days; older replays can create duplicates. We set $insert_id automatically per event — preserve it through any relay.