Review how your ChatGPT Ads integration handles oversized customer-information arrays before relying on automatic retries. A newly observed change in OpenAI’s Conversions API documentation makes this a useful moment to check payload builders, especially when several systems contribute identifiers.
Documentation checked October 16, 2026. The wording differs from the October 15 version we reviewed. This establishes a documentation change, not the date when backend enforcement began. GPTAd did not test a live advertiser account.
What the current documentation says
Each submitted list permits at most three values. If singular and plural forms are both supplied, each merged field permits at most three unique values. Exceeding either limit returns HTTP 400; values are not truncated. The earlier wording described ignoring extras. Read the current Conversions API reference before changing your integration.
Review the payload builder, not just the sender
Start where customer information enters the measurement pipeline. A checkout service, CRM export and analytics adapter may each contribute a different representation of the same field. An individual source can look reasonable while the combined output crosses a boundary.
GPTAd recommends drawing a small ownership map: which service chooses values, which service normalizes them, which service merges records and which service validates the final request. Assign one owner to the final payload contract. Avoid a situation where every upstream team assumes the receiving API will clean up excess information.
Do not automatically expand data collection to fill every available slot. Review whether each value is appropriate for the event and permitted for the intended measurement purpose. Use synthetic fixtures and redacted logs during engineering review rather than copying customer identifiers into tickets.
A practical boundary-test worksheet
The following is GPTAd’s proposed test design, not an official test suite. Record fixture name, input shape, expected local validation outcome and observed result. Keep the tests independent of real customer data.
Test a representative field with one, two and three values, then four. Separately test a mixed singular/plural input that produces three distinct values and another that produces four. Include a duplicate-containing input so that your team does not confuse the submitted-list length check with the merged-unique-value check.
Make your expected behavior explicit before running anything. If the payload builder rejects an oversized fixture locally, verify that the event is routed for investigation rather than silently discarded. If an adapter selects a subset, document that business decision and its ownership instead of making an arbitrary selection inside retry code.
Make rejected requests actionable
GPTAd recommends separating transport failures from payload-contract failures in monitoring. Repeatedly sending the same invalid payload is not a repair strategy. Preserve a redacted diagnostic record, identify the producing component and fix the construction rule before retrying eligible events.
A useful alert includes the integration version, field name, value count and request outcome without revealing the underlying customer information. Review how your pipeline marks records as delivered, pending or rejected. A successful queue operation should not be treated as proof that the receiving service accepted the event.
A related Android documentation clarification
The Supported Events page now explicitly advises including events[].user.android_advertising_id when available for Android app events and says IDFA is unsupported. This is additional guidance, not evidence of a new iOS capability or a newly launched mobile SDK.
If your implementation includes app measurement, add that guidance to the same review. Keep platform-specific mapping separate from your web-event assumptions, and ask the responsible engineer to verify the current reference against the actual integration.
Where this fits in your measurement review
Use this focused check alongside GPTAd’s event-contract and deduplication guide, rather than rebuilding an otherwise working measurement architecture. Save the reviewed documentation date, test results and responsible owner. The goal is a visible, repairable validation boundary, not a claim that more identifiers guarantee better advertising results.
Related: conversion event contracts and deduplication
Related: designing Pixel and CAPI measurement
