Pixel Helper cannot see a Conversions API POST. A 200 is not the contract.

A checkout worker sends a Purchase to Meta Conversions API, and the response is an HTTP 200. The subsequent action often involves obtaining a new access token. However, Pixel Helper fails to detect the POST entirely. The 200 status code signifies that the server is alive, but the body of the request is what truly matters. Meta Pixel Helper, TikTok Pixel Helper, and Google Tag Manager preview all monitor the browser.

Conversion API events are POST requests originating from backend servers, server-side Google Tag Manager, or a queue worker. These events do not appear in Chrome's Network tab unless they have been proxied through the page. Debugging a server-side event within Pixel Helper can lead to the conclusion that the server is down, especially when the event_time is thirteen digits long.

A CAPI tester validates the JSON for proper formatting before shipment. An HTTP 200 response alone does not validate the data and should not be considered a pass. The Conversion API validator checks for required fields, correct data types, timestamp units, hashed identifiers versus raw identifiers, action_source enums, event_source_url when the source is the web, and value and currency for monetary events.

Each issue has a unique identifier, severity, suggested fix, and a link to the vendor's documentation. A pass only confirms that the event adheres to the published envelope structure, not that the event actually occurred. It does not register in the Events Manager, create a click ID, or query the Graph API. Passing the validator means the artifact matches the expected format, but it does not imply the event was successfully attributed.

Pixel Helper is useful for examining the browser pathway: event name, event ID, value, and whether two base codes triggered PageView. Use the validator to verify the JSON, and only include the test_event_code in the production POST if necessary. Leaving it on the live request can lead to a green QA panel masking a pipeline that never processes the data.

The typical initial body appears as follows: data: [{ event_name: Purchase, event_time: 1770000000000, action_source: website, user_data: { em: buyer@example.com } }]. The event_time is formatted with thirteen digits, whereas Meta specifies Unix seconds, which are ten digits long and can only cover seven days. A millisecond value indicates a future timestamp.

Meta requires a SHA-256 hashed version of a normalized email address, along with the client's IP address and user agent in plain text. The action_source field is set to "website" without an event_source_url. The Purchase event lacks a custom_data.value and custom_data.currency fields. Meta expects a SHA-256 hashed email, plaintext client IP address, and user agent, and a numeric value with an ISO 4217 currency code.

Other platforms follow similar validation processes. For instance, PostHog returns HTTP 200 when either the event or distinct_id is missing, and does not ingest the row. Segment's HTTP Tracking API returns a 200 even if no event name is provided, and Segment requires either a userId or anonymousId. GA4 Measurement Protocol returns HTTP 204, which indicates the request was accepted for processing but not that the event was successfully recorded.

Google's debug endpoint provides additional details, while a production collection might store a misspelled event name as a custom event and proceed. Meta sometimes returns a 200 with an error object in the JSON or a batch with per-event errors later. Reading the JSON response is crucial. A gateway 200 response from a proxy in front of the vendor provides limited information, as nginx may be operational, but the validation of the request body remains incomplete.