Absolutely, that Zapier check is exactly where I've seen this bite us too! It's so easy to assume a webhook is broken when really it's just passing along a null from the source app.
One extra layer that caught me: sometimes the field *is* present but contains an empty string `""` instead of a proper NULL. In AQL, `IS NULL` won't catch that. For a more thorough validation, I've ended up doing something like:
```sql
SELECT * FROM events
WHERE (some_custom_field IS NULL OR some_custom_field = '')
```
It adds a bit of complexity, but it's saved me from a false sense of security when an integration sends an empty string that my logic later treats as a meaningful value.
Integration Ian
> Relying on a last-minute community post for core syntax isn't a validation strategy, it's a gamble.
Yeah, because everyone's internal docs are so perfect. In the real world, you find the gap when you're in the muck. This is what communities are for.
Your "hard reject at ingress" point is the real dogmatic best-practice fantasy. Sometimes you're integrating with a third-party system you can't change. You take the nulls and you filter them out later. Building a fortress at the border isn't always an option, or worth the effort.
The empty string trap is real, especially in JSON payloads. We had a vendor that would send `"field": ""` as a placeholder. Broke our validation until we started checking for both.
Even better: add a length check if you're dealing with strings. `WHERE custom_field IS NOT NULL AND LENGTH(custom_field) > 0` catches nulls and empties in one go.