Pinterest Conversion Events: The v5 Payload Field by Field
Pinterest conversion events POST to a single endpoint - POST /v5/ad_accounts/{ad_account_id}/events - and each event is a compact object: a name, an action source, a timestamp, an identifier, and the user data that makes matching possible. The official v5 reference shows the exact shape, and the fields that look optional matter more than they seem: event_id carries deduplication, user_data carries matching, and the privacy flags decide whether Pinterest may use the event at all.
The Core Fields
| Field | What it carries | Notes from the v5 reference |
|---|---|---|
event_name | The conversion type: checkout, add_to_cart, page_visit, signup, and the documented set | Custom events ride the same endpoint |
action_source | Where the event happened: web, app_ios, app_android, offline | Drives source-level reporting |
event_time | Unix timestamp of the conversion | Delivery as close to real-time as possible - Pinterest names under one hour |
event_id | The event's unique identifier | The deduplication key for the recommended dual delivery - see event ID deduplication |
event_source_url | The page URL for web events | Reporting context |
The reference sample shows the combination in one object: event_name checkout, action_source app_ios, a Unix event_time, and event_id eventId0001 - the minimal identity of one conversion.
user_data: The Matching Material
The user_data object carries the identifiers Pinterest matches against real accounts, with the hashed email (em) as the lead field the reference shows as an array. Hashing follows the canonicalization discipline - lowercase, trimmed, SHA-256 - and a wrongly normalized value does not error out; it simply matches nobody. How the per-platform rules differ is collected in CAPI user data hashing and normalization, and the browser-side complement is Enhanced Match, which sends hashed emails from the tag when the Pinterest cookie is absent. To send one event by hand while the pipeline is being built, the free Pixel Activator formats this payload without code.
Privacy Switches and Partner Identification
The v5 payload includes opt_out and advertiser_tracking_enabled - the switches that tell Pinterest whether the event may be used for the user in question - and Pinterest's Conversions API additionally documents the Limited Data Processing flag for state privacy laws. partner_name labels the sending integration (the reference shows an S2S partner string), which is how Pinterest distinguishes tag traffic from server traffic in its reporting. For a tracker-driven pipeline these fields are static configuration: set once by the delivery layer per campaign's consent posture.
Responses: What Pinterest Answers
The v5 reference documents the responses cleanly: 200 - "The request has succeeded"; 400 - "The request could not be understood by the server due to unexpected data", which is a payload problem (malformed fields, wrong types); 401 - an authentication problem with the token. The full code table with fixes is in Pinterest Conversions API error codes, and the credentials behind the 401s in Pinterest Conversions API setup. The cluster overview is the complete guide.