An event handler may receive an event type that the application does not yet use. That can happen during a provider update, a destination configuration change, or a test. Unknown does not automatically mean malicious, but it also does not mean safe to interpret as a familiar event.
Keep authenticity checks first. Then choose an explicit policy for supported and unsupported types.
Route by an allowlist
Map known event types to small handlers that validate their own required fields. Avoid a broad default branch that treats every payload as a catalog update. Two event families can use similar field names with different meanings.
For an authentic but unsupported type, follow the provider's response guidance. You may record a safe event identity and type for review without performing business writes. Do not store unnecessary personal payload fields merely because the event is unfamiliar.
Keep unknown-event monitoring separate from an alert for every rejected attack. A new supported type should be noticeable without producing a flood of identical operational messages.
Test schema changes deliberately
Send a verified fixture with an unrecognized type, one with an extra optional field, and one missing a required field for a known type. These cases should not all share the same outcome.
An additive field may be compatible with your existing handler. A missing required identifier should stop the relevant operation. A new type needs a new reviewed mapping before it changes application state.
This approach makes evolution manageable. The application can keep receiving ordinary traffic while the team decides how to support a new event, and it avoids the dangerous shortcut of treating every valid signature as permission to guess what the message means.