Snapchat Conversions API: The Complete Guide

The Snapchat Conversions API is Snap's server-side channel for conversion data: your server, tracker, or CRM posts events straight to Snap instead of relying on the browser pixel or the app SDK. This page is the front door to our Snapchat CAPI cluster: what the API covers, the match key it requires, how deduplication and validation fit together, and where each specific problem has its own deep-dive guide.

What the API Covers - and the One Hard Requirement

Snap positions the Conversions API alongside the Snap pixel and the App Ads Kit SDK as equivalent ways to feed measurement; delivered events unlock post-view and post-swipe reporting, custom audiences, optimization, and Dynamic Ads. The hard gate sits in the payload: every event needs at least one match parameter - hashed email, hashed phone number, IP address with user agent, or a mobile advertising ID - and a request without any of them errors out. That single requirement separates working integrations from silently broken ones.

The setup path - token generation in Business Manager, the first event, and the credential mistakes - is in Snapchat Conversions API setup, and the token's scope rules in the token guide.

The Payload: Fields, Hashing, Event Types

Snap's parameter reference is explicit about the order of operations: normalize first, hash second. Email is lowercased and trimmed, phone numbers lose every non-digit but keep the country code, names and cities go lowercase without punctuation - and every hashed value becomes a 64-character lowercase hex SHA-256 digest. Fields that must not be hashed (client_user_agent, the click and cookie identifiers) are documented as plainly as the ones that must, and the device IP arrives pre-hashed as hashed_ip_address, SHA-256 like the contact fields. The click identifier rides in sc_click_id, taken from the landing URL's &ScCid= parameter, with the full URL in page_url encouraged alongside. Event types are a fixed UPPER_SNAKE_CASE enum - PURCHASE, START_CHECKOUT, ADD_CART, SIGN_UP, SUBSCRIBE, PAGE_VIEW, SEARCH and the rest - plus five CUSTOM_EVENT_1 through CUSTOM_EVENT_5 slots. The field-level map is in Snapchat conversion events, and the tracker-side wiring in the Keitaro Snapchat integration.

Deduplication: client_dedup_id and the Clock

Snap expects several integrations running at once, and deduplication is coordinated by client_dedup_id: identical across pixel, App Ads Kit, and API for the same event, honored within a 48-hour window of the first occurrence. For purchases, transaction_id carries order-level identity. The delivery clock is generous by platform standards - event timestamps may be up to 37 days in the past - which makes Snap the most forgiving network for a tracker backlog, though the match key requirement remains the harder constraint. The mechanics sit in event ID deduplication and the parameter matrix.

Validation, App Events, and Attribution

Snap's Test Event mechanism mirrors the payload exactly - a test that would fail in production fails in the test, valid fields stay silent, and non-fatal warnings surface based on data quality. App conversions arrive through mobile measurement partners with the app identifiers the payload documents (madid, idfv, anon_id); the MMP path is in Snapchat app conversions via MMP. Attribution defaults to a 28-day click and 1-day view window - the combination Snap recommends - and the discrepancy checklist against trackers is in Snapchat attribution window and discrepancy. Errors and their fixes are in Snapchat Conversions API errors, and the sGTM delivery pattern in Snapchat Conversions API via server-side GTM.

Snapchat Conversions API: Frequently Asked Questions

Sources