Server-side events · Platform reference

Snap Conversions API (v3): events, fields and dedup rules

Snap Conversions API v3 takes batches of web, app and offline events at tr.snapchat.com/v3/{pixel_id or snap_app_id}/events, usually alongside the Snap Pixel. Events arrive but don't attribute when the ScCid click ID and the _scid cookie aren't passed through, when identifiers aren't normalised before hashing, or when the server event_id doesn't match the Pixel's client_dedup_id.

Read from the official documentation on 9 November 2026. Sources are listed at the end.

Endpoint and authentication

POST https://tr.snapchat.com/v3/{PIXEL_ID}/events?access_token={TOKEN}

access_token query parameter: a long-lived token generated on the Business Details page of Ads Manager (visible only to Organization Admins). It can only send events for pixels and apps in the same organisation

Standard event names

Spelled exactly as Snapchat expects them. A near miss is treated as a different event.

Event	Use it for
PURCHASE	custom_data.value is required for PURCHASE; validate returns INVALID if price or currency is missing
SIGN_UP	sign-up
START_CHECKOUT	checkout started
ADD_CART	add to cart
ADD_BILLING	billing info added
VIEW_CONTENT	content or product view
PAGE_VIEW	page view; the minimal web example
SUBSCRIBE	subscription
SEARCH	search
SAVE	save
LOGIN	login
SHARE	share
AD_CLICK	ad click
AD_VIEW	ad view
CUSTOM_EVENT_1 ... CUSTOM_EVENT_5	custom event slots

Required and recommended fields

Field	What it needs
event_name	Required for all web and app events
event_time	Epoch timestamp, second or millisecond granularity; required for web and app events
action_source	WEB, MOBILE_APP or OFFLINE; required for web and app events
event_source_url	Required for web events. Passing the full landing URL lets the API pull the click ID out of it
event_id	Advertiser-chosen unique ID. With the Snap Pixel it must match client_dedup_id; send it on all events on all integrations
user_data	Hashed and unhashed identifiers (see matchKeys)
custom_data.value + custom_data.currency	value and currency (ISO 4217) are both required for PURCHASE
custom_data.order_id	Order identifier; pairs with the Pixel transaction_id for PURCHASE dedup

Match keys and hashing

Key	Normalise and hash
em	Trim leading and trailing whitespace and lowercase, then SHA-256 as lowercase hex
ph	Include the country code, remove any leading 00 or 0, strip non-numeric characters (spaces, parentheses, +, -), then SHA-256 lowercase hex
fn / ln	Lowercase, no punctuation, special characters UTF-8 encoded, then SHA-256
ct	Lowercase, no punctuation or spaces, then SHA-256
st	US: 2-letter lowercase ANSI code; elsewhere lowercase with no punctuation, special characters or spaces; then SHA-256
zp	Lowercase, no spaces or hyphens; US first 5 digits; UK area/district/sector; then SHA-256
country	Lowercase ISO 3166 alpha-2, then SHA-256
ge	SHA-256
external_id	Hashing recommended. Loyalty ID, your own first-party cookie ID, etc.
client_ip_address	Do not hash. IP of the device, not your server; IPv4 or IPv6
client_user_agent	Do not hash. Recommended for all web and app events
madid	Do not hash. Lowercase, keep the hyphens

Click ids

Click id	Where it comes from
sc_click_id	The value of the &ScCid= query parameter Snap appends to the landing URL on an ad click. Do not hash. Snap also asks you to pass the full landing URL
sc_cookie1	The _scid first-party cookie the Snap Pixel sets on your domain. Do not hash. Snap 'highly recommends' it to raise match rate

Deduplication

Pixel client_dedup_id must be identical to CAPI event_id, and event_name must match the event passed to snaptr('track', ...).
Cross-channel dedup window (Pixel client_dedup_id <-> CAPI event_id): 48 hours.
PURCHASE: Pixel transaction_id <-> CAPI custom_data.order_id dedups for up to 30 days. If both pairs are present, the dedup-id pair takes precedence.
event_id must match exactly across Snap Pixel, third-party connectors and direct CAPI calls.
For non-purchase app events, dedup is anchored on device identifiers plus app_id.

Time limits and batch sizes

The Parameters page says event_time can't be more than 7 days in the past. The Introduction page says events can be at most 37 days old to be reported via the Conversions API. Plan for 7.
Up to 2,000 events per batch request.
Standard rate limit: 10 requests per second; Snap recommends a 1,000 QPS limit for long-lived tokens.
Conversions API V2 was scheduled for deprecation in early 2025, so use v3.

How to test before you trust it

Validate endpoint: POST https://tr.snapchat.com/v3/{pixel_id}/events/validate. It returns status VALID, or INVALID with HTTP 400 for problems such as a PURCHASE missing price or currency, or unhashed PII.
Request Check Tool: Validates a CAPI v3 request data object against your Pixel ID and token before you go live.
Events Manager test events: Send test events and view them in Events Manager. The metadata endpoint returns test event logs from the past 24 hours, and the stats endpoint gives the past hour's count and latest timestamp.

Why events arrive but don't attribute

The ScCid click ID is lost (stripped by a redirect, or never stored), so neither sc_click_id nor the full landing URL reaches the API and the conversion can't be tied to the swipe.
_scid cookie not sent as sc_cookie1, or sc_click_id / sc_cookie1 sent hashed. Snap says not to hash either.
Identifiers hashed before normalising: e.g. email not lowercased, or phone with +, leading 00 or spaces. Snap requires normalisation BEFORE SHA-256.
Server event_id doesn't equal the Pixel's client_dedup_id, or event names differ, so the conversion is double-counted instead of merged. The window is only 48 hours.
PURCHASE sent without value or currency: validate rejects it.
client_ip_address set to your server's IP instead of the user's device. Snap asks for the device IP.
event_time more than 7 days old, which the Parameters page disallows.

Sources

Platforms change these rules without notice. If a source says something different from this page, the source wins.

Other platforms

All platforms