Webhooks
Notify an external system when supported ticket events occur and verify secure delivery.
On this page
Overview
Webhooks POST JSON about ticket events to URLs you register. Delivery is queued (system cron in production). Failures appear in integration logs and can retry. This is outbound from HelSup, not IMAP and not a customer messenger.
When to use this
ERP or logging stacks should learn about new tickets without polling REST every minute.
Where to find the controls
Settings → Integrations → Webhooks view. Logs: integration logs. Queue depth: System Status.
Who can make these changes
manage_integrations to CRUD endpoints. The receiving system uses the signing secret you set.
Before you begin
Add URL, secret, event list, and active flag. Verify TLS. Exclude secrets from backups you share. Rate and batch follow queue_batch_size.
Follow these steps
- Stand up an HTTPS listener.
- Register the webhook.
- Trigger a ticket event.
- Confirm the POST and signature.
- Return 2xx.
- On 5xx, watch retry after cron.
Settings reference
URL, secret, events, active, last status, last error, next retry. Payload includes ticket id and event name — treat PII per Privacy settings.
Example workflow
Event ticket.created POSTs to https://hooks.example.com/es. The listener writes a row in the ERP. Slack remains a separate optional connector.
Good practices
Idempotency: store event ids so retries do not double-create ERP rows. Keep listeners fast; do heavy work asynchronously.
Important considerations
HTTP listeners on HTTP (no TLS) leak ticket metadata. Do not log raw secrets. A dead cron looks like “webhooks broken”.
If something does not work
Webhook failed: non-2xx, TLS error, DNS, or queue backlog. Diagnose logs + System Status cron. Contact support if 2xx is recorded but your listener never ran — include timestamps, not the secret.