Why a Zod schema for a PostHog event?

PostHog's properties bag mixes SDK $-prefixed keys with your custom keys; the SDK adds keys silently across versions. A Zod parse at the destination (warehouse loader, capture forwarder) catches an SDK upgrade adding a field your column doesn't know about.

Single event or batch?

Either. /capture accepts both shapes ({ ...event } and { batch: [...] }). Generate from whichever you send and the converter captures the matching schema. Combine with z.union if your downstream consumes both.

Will custom property names be typed?

Yes if they're in the sample. Custom properties are walked literally and become named z.string()/z.number() etc. Unknown future properties become a sibling z.record(...) only if you explicitly add it.

JSON→TypeScript

PostHog Event to Zod

Paste a posthog event JSON payload and get a Zod z.object schema you can run inside your handler. Same shape walker as the TypeScript-mode page, but the output is a runtime-validated schema with .optional() on missing fields and z.union for nullables.

JSON input valid

Zod output

About this conversion

PostHog events mix SDK-injected $-prefixed keys with your own custom property names. A parse at the destination (warehouse loader, server-side capture forwarder, webhook export consumer) catches an SDK upgrade adding a field your downstream column doesn't know how to write.

PostHog destinations and warehouse loaders are server-side; they care about validation strictness and good error messages more than bundle KB — Zod's named-error chain is the practical choice when an SDK upgrade introduces a new $-prefixed key. The output is a copy-paste-runnable z.object using only standard Zod primitives (z.string, z.number, z.array, z.union, .optional). Drop it into your handler, run schema.parse(body), and the rest of your code consumes a strongly typed value with no ambient unknowns.

PostHog Event to Zod

About this conversion

Same shape, other validators

Other JSON shapes