Snapchat Conversions API: Server-Side Setup Guide

Last month I audited tracking for a DTC skincare brand spending EUR 12,000 a month on Snapchat Ads. Their Snap Pixel was firing on every page load, but Events Manager showed a 38 percent drop in attributed purchases compared to Shopify. The culprit was familiar: Safari's ITP capping JavaScript-set cookies to seven days, ad blockers stripping the pixel request, and a checkout redirect that broke the cookie chain entirely. The fix was the Snapchat Conversions API.

If you run Snapchat campaigns and rely only on the browser pixel, you are under-counting conversions. This guide covers what the Snapchat Conversions API is, how to set it up, and how to avoid the deduplication and match-quality pitfalls I see on every account I touch.

What the Snapchat Conversions API actually does

The Snapchat Conversions API (CAPI) is a server-to-server integration that lets you send web, app, and offline conversion events directly from your server to Snap's endpoint. Instead of relying on a JavaScript tag in the user's browser, your back end fires an HTTPS POST to https://tr.snapchat.com/v3/{PIXEL_ID}/events with the event payload and hashed user identifiers.

This matters because the browser path is increasingly unreliable. Safari ITP caps client-side cookies at seven days. On iOS, ATT opt-in rates sit at roughly 35 percent globally as of Q2 2025 — meaning about two-thirds of iOS users cannot be reached by the pixel alone. And any ad blocker or privacy extension can silently kill the Snap Pixel request before it leaves the page.

If you have already set up server-side tracking for Meta or LinkedIn, the concept is identical. I covered the pattern in my plain-English guide to Conversions APIs and in the server-side tracking deep-dive. Snapchat's implementation follows the same playbook, with a few platform-specific differences I will walk through below.

Why performance advertisers should care

Snapchat now reaches 483 million daily active users as of Q1 2026, and ad spend on the platform is forecast to hit $5.27 billion this year. For performance advertisers, the channel is no longer experimental. But Snap's ad delivery algorithm optimizes toward the events it can see. If half your purchases never reach Snap because the pixel was blocked, the algorithm starves.

Snap's own data makes the case clearly. Advertisers who integrate both the Snap Pixel and the Conversions API see, at the median, a 22 percent increase in attributed purchases, a 25 percent improvement in purchase value, and an 18 percent improvement in cost per purchase. For iOS app advertisers with an MMP and CAPI, the numbers are even more dramatic: nearly 50 percent more attributed installs and over 30 percent better cost per install.

Those are attribution gains, not magic revenue increases. But attribution gains feed the optimization loop: more signal, better delivery, lower CPA. If your snapchat conversion tracking is pixel-only today, you are leaving money on the table.

Prerequisites before you start

Before writing any code or configuring a tag, you need four things:

Requirement	Where to get it
Snap Pixel installed on your site	Snapchat Ads Manager > Events Manager
Pixel ID	Events Manager > Pixel settings
CAPI access token	Business Manager > Business Details > Conversions API Tokens (requires Org Admin)
Server environment or sGTM container	Your hosting provider or a service like Stape, Addingwell, etc.

The CAPI token generation requires Organization Admin permissions in Snapchat Business Manager. If you do not have that role, get it before you begin — I have seen setups stall for weeks because the token request sat in someone's inbox.

Setting up the Snapchat Conversions API step by step

There are two main routes: a direct server-to-server integration (you write code) or a server-side Google Tag Manager (sGTM) approach using the community tag template. I will outline both.

Route 1: Direct API integration

1. Build the event payload. Every CAPI request is a POST to https://tr.snapchat.com/v3/{PIXEL_ID}/events with the access token as a query parameter. The required fields for every event are:

• event_name — the conversion event type (PURCHASE, SIGN_UP, ADD_CART, PAGE_VIEW, etc.)
• event_time — epoch timestamp in seconds or milliseconds
• action_source — WEB, OFFLINE, or MOBILE_APP
• event_source_url — the full URL where the event occurred (required for web events)

2. Attach user identifiers. Events without at least one valid user identifier will be rejected. The user_data object accepts hashed email (em), hashed phone (ph), client_ip_address, client_user_agent, sc_click_id, sc_cookie1, and external_id, among others. Email and phone must be SHA-256 hashed after normalizing (lowercase, trimmed). IP address, user agent, and click IDs are sent in plain text.

3. Include deduplication identifiers. Set event_id at the top level of each event. For purchase events, also include order_id inside custom_data. I will cover why this matters in the deduplication section below.

4. Send the request. A minimal PURCHASE payload looks roughly like this:

{
  "data": [
    {
      "event_name": "PURCHASE",
      "event_time": 1753612800,
      "action_source": "WEB",
      "event_source_url": "https://example.com/thank-you",
      "event_id": "evt_abc123",
      "user_data": {
        "em": "a1b2c3...sha256hash",
        "client_ip_address": "203.0.113.50",
        "client_user_agent": "Mozilla/5.0...",
        "sc_click_id": "xxxxxxxx-xxxx"
      },
      "custom_data": {
        "currency": "USD",
        "value": "49.99",
        "order_id": "order_7891"
      }
    }
  ]
}

5. Verify in Events Manager. After sending test events, check Snapchat Events Manager for incoming server events. Snap provides diagnostic information there, including whether your events are being matched and deduplicated correctly.

Route 2: Server-side GTM

If you already run a server-side GTM container — and you should if you advertise on multiple platforms — the conversions api snapchat setup is simpler.

1. In your sGTM container, go to the Community Template Gallery and search for the Snapchat Conversions API tag template.
2. Add your Pixel ID and CAPI token.
3. Map your existing sGTM events (purchase, add_to_cart, etc.) to Snap event names.
4. Make sure the tag reads sc_click_id from the URL query parameter (ScCid) and passes it through. This is the single most important identifier for attribution.
5. Set the event_id parameter to match what your browser-side Snap Pixel sends, enabling deduplication.

The sGTM route is what I recommend for most advertisers because it centralizes your server-side tracking for Snap, Meta, LinkedIn, and others in one container. I described the same pattern for Meta's CAPI setup and for LinkedIn's server-side integration — the architecture is reusable.

Deduplication: the part most setups get wrong

If you send the same conversion through both the Snap Pixel and the Conversions API without proper deduplication, Snap will count it twice. I see this constantly. A client's Events Manager shows double the purchases Shopify recorded, CPAs look artificially low, and the optimization algorithm over-delivers to audiences that are already converting.

Snap deduplicates on two identifier pairs, each with a different window:

Identifier pair	Dedup window
client_dedup_id (Pixel) matched to event_id (CAPI)	48 hours
transaction_id (Pixel) matched to order_id in custom_data (CAPI)	30 days

The 48-hour window covers everyday page-view and add-to-cart events. The 30-day window exists specifically for purchase events, where the server-side confirmation might arrive well after the browser event.

Best practice: for purchase events, send both identifier pairs. Use a UUIDv4 or your internal event ID for event_id/client_dedup_id, and use your actual order number for order_id/transaction_id. Never use placeholder values. If your Snap Pixel fires snaptr('track', 'PURCHASE', {client_dedup_id: 'evt_abc123', transaction_id: 'order_7891'}), your CAPI payload must carry the same values in event_id and custom_data.order_id respectively.

If you are not sure whether your current snapchat conversion tracking is double-counting — or under-counting — I can audit it for you. It usually takes me less than a day to map out exactly where events are leaking or duplicating.

Improving Event Match Quality

Event Match Quality (EMQ) is Snap's score for how effectively the user identifiers you pass can be matched to a Snapchat account. Higher EMQ means more conversions are attributed, which means more signal for the algorithm.

The parameters that matter most, in rough order of impact:

1. sc_click_id — parsed from the ScCid URL parameter when a user clicks or swipes up on your ad. This is the highest-value identifier because it ties the event directly to an ad interaction.
2. Hashed email (em) — normalize to lowercase, trim whitespace, then SHA-256 hash.
3. Hashed phone (ph) — E.164 format, then SHA-256 hash.
4. client_ip_address and client_user_agent — sent unhashed. These enable probabilistic matching when deterministic identifiers are missing.
5. sc_cookie1 — the first-party cookie set by the Snap Pixel. If you are running both the pixel and CAPI, pass this value through.
6. external_id — your own user identifier, hashed. Useful for logged-in states.

The single biggest mistake I see is ignoring sc_click_id. If your landing-page URL strips query parameters — common with redirect setups or vanity URL tools — the click ID is lost before it reaches your server. Check your landing pages. Open a Snapchat ad in a test environment. Confirm ScCid survives through to the conversion page.

Common pitfalls and how to avoid them

Token revocation. Snap CAPI tokens do not expire automatically, but they can be revoked if an Org Admin regenerates them. Monitor Events Manager for sudden drops in server events.

Stale event timestamps. Snap allows backdating up to 37 days, but send events as close to real time as possible. Batch delays beyond a few minutes hurt campaign performance.

Missing action_source. If you send WEB events without event_source_url, or set the wrong action_source, Snap will reject or misclassify the event. Every web event needs the full URL including protocol.

Double-hashing. If your CDP pre-hashes email addresses and your CAPI integration hashes again, the value will never match. Check once, hash once.

Not testing with real ad traffic. The sc_click_id only exists on clicks from real Snap ads. You cannot fully test attribution without running a real campaign and clicking through.

Putting it all together

The implementation sequence I follow for most clients:

1. Audit the existing Snap Pixel — confirm it fires the right events with the right parameters.
2. Set up the CAPI token and server environment (direct integration or sGTM).
3. Map events and ensure event_id/client_dedup_id are shared between pixel and CAPI.
4. Enrich CAPI events with hashed email, phone, IP, user agent, and sc_click_id.
5. Verify in Events Manager — check for deduplication status and EMQ indicators.
6. Monitor for seven days, comparing attributed conversions against your source of truth (Shopify, CRM, backend database).

For the DTC skincare brand I mentioned at the top, this process took three days. Attributed purchases in Snap Ads Manager climbed 31 percent within the first week — not because sales increased, but because Snap could finally see what was already happening. Their target CPA campaigns started spending budget again instead of throttling.

If you are running Snapchat ads at any meaningful scale and do not have the conversions api snapchat integration in place, you are optimizing blind. The same logic applies across platforms — I have written similar walkthroughs for X/Twitter's Conversion API and for Google's Enhanced Conversions. The browser-only era is over. Server-side is the baseline.

FAQ

Not sure your Snapchat tracking is actually working? Let me audit it — I will tell you exactly where events are leaking, duplicating, or misattributed, and hand you a plan to fix it.