Segment's 200 means it got your bytes, not that your event shipped

A collector's job ends at the byte count. Segment's tracking endpoint answers 200 to a batch whose `track` row carries no `event`, and the drop happens after that answer and before any destination ^[1]. The spec marks `event` as required, the collector takes the call anyway, and it does not invent a name for you ^[2]. What the 200 asserts is that bytes were received ^[3]. Anything watching for non-2xx responses therefore has no signal to fire on, and the shortfall only becomes visible wherever events are counted at the far end.

The required-field list is short, which is what makes the silence irritating rather than merely unfortunate. `event` is only required on `track`; `identify`, `page`, `screen`, `group` and `alias` do not need it, so a mixed batch fails only on its track rows ^[5]. A batch row must carry `type`, and the value has to be one of those six ^[11] - which means five of the six accepted row types pass the event-name contract by construction, and exactly one can lose data to it ^[1]. Separately, Segment documents `userId` or `anonymousId` as required on every call, and a track carrying properties and a timestamp but no identity is not associated with anyone: destinations keying on user id see nothing, destinations keying on anonymous id see nothing ^[7].

The linter's own caveats are the useful part of the writeup. On a single call the type lives in the URL path at `/v1/track` rather than in the body, so a body-level `type` check is scoped to batches and stays quiet on a lone payload ^[6]. An empty `writeKey` is flagged, a missing one is not, because the key may be travelling as HTTP basic auth in a header that a JSON fixture cannot show ^[8]. That is the honest boundary of pre-send checking: a fixture is not the wire, and the pack matches Segment payloads by host or by body shape and will lint a fixture with no host at all ^[13].

Timestamps are where the same mistake stops being portable. Segment documents `timestamp` as an ISO 8601 date string, an epoch number is the wrong type, and for events happening now the advice is to omit the field and let Segment stamp it ^[9]. PostHog's capture takes the same ISO 8601 shape but reads an epoch value as ingestion time rather than the time you sent; Amplitude wants milliseconds; there is no default timestamp type at this layer ^[10]. One integer, three outcomes, none of them an error you will see in a response code ^[2].

Pixellint, whose Segment pack produced these findings, is an open source payload linter and is independent of Segment; the rule ids cite the HTTP API and track spec because that is where the requirements are documented, not because this is an official tool ^[14]. Read the findings as a reading of Segment's own docs, not as vendor behaviour anyone has certified. The operational point survives either way: the receiver acknowledges receipt and validates nothing, so the check has to happen before the send.