Event Types
Event types let you categorize webhooks and route them to the right endpoints. Without them, every webhook goes everywhere.
The Problem
If your application sends different kinds of events β order updates, user signups, payment confirmations β you probably want different endpoints to handle them. Your order processing service shouldn't receive user signup events.
Without event types, you'd need to filter on the consumer side, wasting bandwidth and processing time.
How Event Types Work
Event types are string identifiers that describe what happened. They follow a resource.action pattern:
order.createdorder.updatedorder.cancelledpayment.succeededpayment.faileduser.createduser.updatedinvoice.paidYou can use any string format, but resource.action is recommended for consistency.
Registering Event Types
Event types are automatically registered when you send a webhook. No pre-registration required:
curl -X POST https://hooksniff-api-1046140057667.europe-west1.run.app/v1/webhooks \
-H "Authorization: Bearer hr_live_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"endpoint_id": "ep_abc123",
"event": "order.created",
"data": {"order_id": "12345"}
}'The event type order.created is now available for filtering and search.
Filtering by Event Type
Configure endpoints to only receive specific event types using the event_filter field:
curl -X POST https://hooksniff-api-1046140057667.europe-west1.run.app/v1/endpoints \
-H "Authorization: Bearer hr_live_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://myapp.com/webhooks/orders",
"description": "Order events only",
"event_filter": "order.*"
}'Supported filter patterns:
order.createdβ Exact matchorder.*β Wildcard (all order events)*β All events (default)
Schema Validation
Optionally define JSON schemas for event types to validate payloads before delivery:
{
"event_type": "order.created",
"schema": {
"type": "object",
"required": ["order_id", "total"],
"properties": {
"order_id": { "type": "string" },
"total": { "type": "number", "minimum": 0 },
"currency": { "type": "string", "default": "USD" }
}
}
}When a schema is defined, payloads that don't match are rejected with a 400 Bad Request error before they even enter the delivery pipeline.
Best Practices
- Be specific: invoice.payment_failed is better than invoice.error
- Use dots as separators: resource.action format
- Version when changing shapes: order.created.v2
- Use wildcards for grouping: payment.* catches all payment events
- Document your event types: Keep a list of all event types your application emits