Overview
Webhook usage is measured per project and calendar month.
Customer-facing counters:
- Endpoints: configured destinations compared with the plan limit.
- Deliveries this month: delivery records created compared with the project allowance.
- Successful: deliveries that received HTTP 2xx.
- HTTP attempts: actual outgoing HTTP requests, including retries.
- Data sent: encoded payload bytes transmitted during attempts.
One event sent to three matching endpoints creates three deliveries. A retry increases HTTP attempts and bytes sent but does not create a new event or a second delivery record.
Setup
Platform-owner controls in Django admin:
Features
Defines the available webhook limit types.
Plan features
Assigns endpoint, monthly delivery, retry-attempt and log-retention limits to each plan. This is the primary table for controlling commercial allowances and profit margins per plan.
Webhook platform settings
Controls global enabled status, worker batch size, request timeout, response capture size, retry ceiling, retry delays, default log retention and private-network target safety.
Webhook monthly usage
Shows queued deliveries, actual attempts, successes, final failures and bytes sent for each project/month.
Webhook deliveries and attempts
Provide operational history for support and diagnostics.
Code example
Example month:
10,000 original events
2 matching webhook endpoints
= 20,000 webhook deliveries
19,500 succeed on first attempt
500 require one retry
= 20,500 outgoing HTTP attempts
Commercial planning should consider attempts and payload bytes,
not only the original event count.Notes
Run python manage.py seed_billing after installing webhook updates so every plan receives the webhook feature limits.
Use conservative allowances until production traffic reveals realistic payload size, response time and retry behaviour. Limits remain editable without hardcoding plan UI values.