Snap CAPI v2 is gone. The v3 path is tr.snapchat.com/v3/{id}/events.

The path carries the id now

v2 put pixel_id in the JSON body and posted to /v2/conversion. v3 puts the Pixel ID or Snap App ID in the path. Web: POST https://tr.snapchat.com/v3/{PIXEL_ID}/events?access_token={TOKEN}. App: the same host with {SNAP_APP_ID} instead of the pixel. The access token is a query parameter. Mixing a Graph-style Authorization header with a v2 body is a different miss from mixing field names.

The migration guide is blunt: the request structure and parameters are different for v3. Send all event data in the body as JSON. The root is a data array of one or more events. Server parameters including event_name sit at the root of each event. user_data holds em, ph, sc_click_id, sc_cookie1. custom_data holds currency, value, contents, order_id. app_data holds extinfo for app events.

Validate before you cut production. Web validate is POST https://tr.snapchat.com/v3/{pixel_id}/events/validate. App validate swaps in snap_app_id. A VALID status on validate is schema. It is not Events Manager attribution. The live events path is the one that trains, the same way Meta test_event_code is not production.

event_name is PURCHASE, not Purchase

The Parameters page lists event_name as required. The enum is SCREAMING_SNAKE: PURCHASE, SAVE, START_CHECKOUT, ADD_CART, VIEW_CONTENT, ADD_BILLING, SIGN_UP, SEARCH, PAGE_VIEW, SUBSCRIBE, AD_CLICK, AD_VIEW, and the rest of that table, plus CUSTOM_EVENT_1 through CUSTOM_EVENT_5. Meta PascalCase Purchase is not in the list. A shared enum named Purchase will be a custom miss or an invalid event depending on how strictly the gate reads the string.

action_source is WEB, OFFLINE, or MOBILE_APP. Meta uses website. Pinterest uses web. Snap uses WEB. Copying the Meta spelling is a silent miss on a vendor that enumerates WEB. event_source_url is required when website events are shared via Conversions API. It must include a protocol. That is not v2 page_url and it is not Meta event_source_url copied onto a v2 body.

If event_name is PURCHASE, currency and value are also required. They live in custom_data, not as v2 price on the root. value is a numeric value associated with the event. currency is a subset of ISO 4217 codes Snap lists on the Parameters page. Sending price: "43" on the root is the v2 example in the migration guide. It is not a v3 purchase.

Two clocks, two windows, one field

event_time is an integer Epoch timestamp. Snap says it can handle second-level or millisecond-level granularity and encourages milliseconds. Date.now() is already milliseconds. Math.floor(Date.now() / 1000) is the Meta helper. Both can be legal on Snap. A string timestamp like the v2 example "1642815764" is the old type.

The Parameters page says event_time cannot be more than 7 days in the past for web and app events. The introduction page still says events can have a date of maximum 37 days back to be eligible. The older v2 conversion reference said timestamp cannot be more than 37 days in the past. Do not invent which gate fires in production. Send a recent event_time. Do not backfill a month of v2 leftovers onto v3 and assume the 37-day sentence still applies.

Dedup is event_id plus timestamp within a 48 hour window. Send event_id on CAPI and on the Pixel. For Snap Pixel non-purchase events, event_id maps to client_dedup_id. For purchase events it can map to transaction_id. UsingTheAPI says always ensure timestamps are accurate. A v3 event with a new event_id and an old v2 timestamp is a different event from the pixel fire you think you are pairing.

The body people will send first

A Snap CAPI v2 conversion body from the migration guide. This is not a v3 event.

{
  "pixel_id": "67d34640-b7a4-42a8-b821-6434d70f08a4",
  "timestamp": "1642815764",
  "event_conversion_type": "WEB",
  "event_type": "PURCHASE",
  "page_url": "https://www.example.com",
  "hashed_email": "8c2a47d3bdb8d3096a6479f53eac3b724291db5f1c31611100f675be5537329d",
  "transaction_id": 123123123123,
  "price": "43"
}

Names that do not translate

• v2 /v2/conversion is v3 /v3/{PIXEL_ID}/events or /v3/{SNAP_APP_ID}/events.
• v2 pixel_id in the body is the path id.
• v2 event_type is event_name.
• v2 event_conversion_type is action_source. WEB stays WEB. It is not website.
• v2 timestamp is event_time. Integer. Seconds or milliseconds. Not a string.
• v2 page_url is event_source_url.
• v2 hashed_email is user_data.em.
• v2 transaction_id is event_id on purchase, paired with the pixel transaction_id.
• v2 click_id is sc_click_id. The query param is ScCid.
• v2 uuid_c1 is sc_cookie1, the _scid cookie, not hashed.

Click id and cookie still have to travel

When a user clicks or swipes up on a Snapchat ad, Snap appends &ScCid= to the outgoing URL. That value is the Click ID. Sending it on CAPI improves measurement. You can parse ScCid into sc_click_id, or pass the full destination URL as event_source_url and Snap will extract it. If checkout is a different host, the query string is gone unless you copied it.

sc_cookie1 should hold the Pixel SDK _scid first-party cookie. If you are not running the Pixel and you have your own cookie, Snap says to pass that id as external_id. client_ip_address and client_user_agent stay plaintext. Hashing the IP because a Meta helper hashed em is how the event becomes unmatchable. em and ph are hashed after the documented normalize steps.

Partners set integration at the event with the partner or connector name. Direct integrations omit that or send their own documented value. App events need app_data with extinfo in the documented order. Missing slots are empty strings, not omitted keys you hoped Snap would ignore. iOS extinfo version is i2. Android is a2.

What to do

Stop posting to /v2/conversion. Put the Pixel ID in the v3 path. Wrap events in data[]. Map your internal purchase to event_name PURCHASE. Convert the clock at the edge: integer Unix time, milliseconds preferred. Persist event_id as a different column from Meta event_id. Capture ScCid on the landing hit and copy it through checkout.

If you run the Pixel, send sc_cookie1 and reuse client_dedup_id or transaction_id as event_id. Validate on /events/validate, then strip the validate path in production. Lint the body you actually POST. The Snap pack is vendor/snapchat. A Meta CAPI fixture cannot serve it.

The contract page for the field list is Snap's Parameters page. This post is the market fact: v2 is the retired hop, and v3 is a different envelope. Pixellint is not affiliated with Snap. Passing a linter means the artifact matches the published v3 envelope. It does not mean Events Manager attributed the order.

Checklist

• POST to https://tr.snapchat.com/v3/{PIXEL_ID}/events?access_token=TOKEN, not /v2/conversion.
• Send data[] with event_name, event_time, action_source, and event_source_url on web.
• Use PURCHASE, not Purchase. Use WEB, not website.
• Put hashed email on user_data.em. Put currency and value on custom_data for PURCHASE.
• Pass sc_click_id or a URL that still has ScCid. Send sc_cookie1 when you have _scid.
• Reuse the pixel client_dedup_id or transaction_id as event_id. Validate, then send live.

Sources

• Snap Conversions API introduction
• Snap CAPI parameters
• Snap CAPI migration from v2 to v3
• Snap CAPI: Using the API

Contract pages

The dated argument is above. These pages are the field lists.

• One CAPI JSON cannot serve every vendor
• Event time units
• Pixel plus CAPI