What is a webhook, and why would I use one?
Normally, if you want to know what is happening in Electric IT Management, you have to log in and check. A webhook turns that around. You give Electric a secure web address belonging to one of your own systems, and the moment something relevant happens, Electric sends that address a notification with the details.
You do not need to be a developer to benefit from this. Tools your team already uses, including Jira Service Management and Slack, can receive these notifications and act on them with no code required.
Electric can send events to Jira Service Management, to Slack, or to any secure endpoint you control.
Some things teams commonly use webhooks for:
-
Employee lifecycle. Create a Jira work item the moment a new hire is added, so their laptop and accounts are queued before day one. Post to Slack when someone is offboarded, so whoever is on duty knows to revoke access right away. Send updates to your own system to keep records in step as job titles and emails change.
-
Employee group membership. Create a Jira work item when someone joins a group that carries software access, so a licence gets assigned. Or post to Slack for a running record of who gained access to what, and when.
-
Groups & membership. Post to Slack when a group is created, changed, or deleted, so a new access boundary does not appear unnoticed. Send the same events to your own system to keep an access model in step with Electric.
-
Tasks. Mirror Support Center tickets into Jira so your team works from a single queue. Onboarding and offboarding raise task events too, so that whole checklist can land in your own tracker.
Before you start
-
You will need Admin access in Electric. Viewing webhooks requires the webhooks read permission, and creating, editing, or deleting them requires the webhooks write permission.
-
You will need somewhere for the notification to go: a secure address you control, or an incoming webhook from a tool you already use.
-
Electric requires a valid, secure (HTTPS) address that resolves to a public host. Plain unsecured addresses, and addresses that resolve to internal or private networks, are rejected.
-
Each organization can create up to 20 webhooks.
Important: Set up your destination system first. You will need its address, and for Jira Service Management its token, before you can finish creating the webhook in Electric.
Choosing a provider
Electric shapes each notification for its destination, so the first thing you choose is a provider.
|
Provider |
Choose this when |
Address must be on |
|---|---|---|
|
Generic webhook |
You are sending events to your own service, or to an automation platform such as Zapier |
Any HTTPS host |
|
Jira Service Management |
You want events to create work items in Jira through an automation rule |
|
|
Slack |
You want events posted as readable messages in a Slack channel |
|
If you paste an address that matches one of these hosts, Electric selects the matching provider for you and shows a banner reading Provider updated automatically. You can change the provider yourself at any time.
What each topic sends you
Every notification tells you which topic it came from, which event fired, when it happened, and includes a data section with the details.
|
Topic |
What it covers |
Events included |
|---|---|---|
|
Employee lifecycle |
An employee's status or profile changing |
|
|
Employee group membership |
An employee joining or leaving a group |
|
|
Groups & membership |
A group itself being created, changed, or removed |
|
|
Tasks |
A task moving through its lifecycle |
|
Important: The topic named Tasks delivers events named request.created, request.completed, and so on. If you are matching on the event name in your own system, use the request. names rather than the word "task".
Every notification has the same outer shape. What changes from event to event is the topic, the event name, and the contents of data.
Payload Preview
Here is an example of the payload of each event, grouped by topic.
Employee lifecycle
Employee group membership
Groups & membership
Tasks
Remember that the Tasks topic uses the topic key requests.lifecycle and request. event names.
On an update event, the notification also carries a previous_attributes section listing only the fields that changed, for example "previous_attributes": {"job_title": "Support Engineer"}. This is useful when you only want to react to a particular field changing.
A few behaviors worth knowing:
-
employee.reactivatedfires only for employees who were previously offboarded, never for newly created ones. -
Group membership events fire once per group, so a change affecting three groups sends three notifications.
-
group.deletedarrives with only the group'sid, because the group no longer exists by the time the event is sent.
Sending to your own endpoint
Choose Generic webhook when you are sending events to a service you run yourself, or to an automation platform such as Zapier or Make. Electric posts its standard notification exactly as shown above, with no reshaping for a particular destination.
Steps in Electric:
-
Log in to Electric
-
Select Settings, then the Webhooks tab
-
Click Create webhook
-
Select Generic webhook as the provider
-
Enter a Name for the webhook
-
Paste your Endpoint URL. There is nothing else to fill in, because the generic provider has no credentials or settings of its own
-
Select your topics
-
Review the payload preview so you know the exact shape your service will receive
-
Leave Active turned on, then Click Create webhook
-
You are all set!
What your endpoint needs to do
-
Accept an HTTP POST with a JSON body. Electric sends
Content-Type: application/jsonand identifies itself withUser-Agent: Electric-Webhooks/1.0. -
Respond within 10 seconds. Anything slower is recorded as a failure and is not sent again. If your processing takes longer than that, acknowledge the notification first and do the work afterwards.
-
Return a status in the 200 range. Anything else is recorded as a failure. Redirects are not followed, so a 301 or 302 is treated as a failed delivery rather than passed along to the new address.
Address requirements
-
The address must use HTTPS. Electric will not save a plain HTTP address.
-
The host must be publicly resolvable. Addresses that resolve to private, loopback, link-local, reserved, multicast, or carrier-grade NAT ranges are rejected. Electric checks this when you save and again at the moment of delivery, so an address that later points inward stops working rather than being delivered to.
-
Unlike Jira Service Management and Slack, the generic provider places no restriction on which host you use.
Recognizing repeat deliveries
Every notification carries an id at the top level. If the same event reaches you more than once, that id stays the same, so your service can record what it has already handled and safely ignore repeats.
Two other details that make parsing easier. Fields with no value arrive as JSON null rather than being left out, so the shape of data stays consistent for a given event type. And test tells you whether the notification came from a test send or a real event.
No native option in your helpdesk? Automation platforms such as Zapier and Make connect to almost any helpdesk without code. Create a Catch Hook trigger, paste the address it gives you into Electric as your endpoint URL, send a test event so the platform has a sample to work with, then add your helpdesk's create-ticket action and map the fields.
Do not have a receiver set up yet? Point your webhook at a free tool such as webhook.site temporarily. It gives you a disposable address and shows the exact notification as it arrives, which is a good way to confirm everything on Electric's side works before wiring it into a real system.
Testing your webhook
Before pointing a webhook at something important, send a test notification.
-
While creating or editing a webhook, click Send test event in the payload preview panel. This works before you have saved the webhook, and shows the real response from your address.
-
For a saved webhook, select Send test event from its row menu on the Webhooks list, or from its detail page.
Test notifications use sample data, a fictional employee or task, and are marked "test": true, so nothing you send while testing looks like a real record on the receiving end.
Electric reports the result as a message on screen. Only a response in the 200 range counts as delivered. A redirect is treated as a failure, and Electric does not follow it.
Important: A successful response means your address accepted the request. It does not confirm the destination did anything useful with it. A Jira rule with an incorrect field mapping still returns a success, so check the destination as well.
Please note: Test events are not added to the delivery log. If you have only ever sent test events, Recent deliveries will still be empty. That is expected, and does not mean the test failed.
In Jira Service Management you can confirm from the other side. Open your rule and view its Audit log to see what Jira received and what it did with it. Atlassian's verification guide covers this in more detail.
Checking delivery history
Open a webhook to see Recent deliveries, which shows the 50 most recent real events, newest first.
|
Column |
What it shows |
|---|---|
|
Time |
When Electric sent the notification |
|
Event type |
The event name, for example |
|
Status code |
The response your endpoint returned, or a dash if it never responded |
|
Latency |
How long the round trip took |
|
Result |
Whether the delivery succeeded or failed |
You can filter the list by All, Success, or Failure.
Please note: Failed rows show a Retry link. It does not resend the original notification. It sends a fresh test event to the same address, so you can check whether your endpoint is working again, and it leaves the failed row as it was.
The log records this summary only. It does not store the contents of the notification or of the response.
Please note: The delivery list does not update on its own. Reload the page to see recent activity.
Limits and delivery behavior
|
Limit |
Value |
|---|---|
|
Webhooks per organization |
20 |
|
Endpoint protocol |
HTTPS only, public hosts only |
|
Topics per webhook |
At least one, no maximum |
|
Delivery timeout |
10 seconds |
|
Delivery attempts |
One, with no retry |
|
Deliveries shown in the log |
50 most recent |
|
Test events |
10 per minute, per IP address |
Important: Delivery is best effort. Electric attempts each notification once and does not try again. If your endpoint is unavailable or slow to respond, that event is recorded as failed and is not resent. If your endpoint has been down, treat the delivery log as a record of what was missed rather than a queue that will catch up.
Managing your webhooks
From the Webhooks list, use the menu at the end of any row to edit a webhook, send a test event, enable or disable it, or delete it.
Turning a webhook off stops deliveries immediately. Its settings are kept, so you can turn it back on at any time. Deleting a webhook removes it and its delivery history permanently, and cannot be undone.
FAQ
I sent a test event and got a success message, but Recent deliveries is empty. Is it broken?
No. Test events are not recorded in the delivery log. The log fills in once real events start firing. Bear in mind that the list also does not refresh on its own, so reload the page after you expect an event.
Are deliveries signed, so my endpoint can verify they came from Electric?
Not today. Signature verification is planned but not yet available, and the signing secret shown on the webhook detail page reads Not enabled for this reason. In the meantime, verify deliveries another way: include a secret value in the endpoint address itself, or restrict your endpoint to traffic you expect.
Why does the Tasks topic send events called request.created?
The topic is named for what you see in Electric, while the event names follow the underlying record. They refer to the same thing. Match on the request. names when you write rules in another system.
Can I subscribe to just one event within a topic?
No. Subscribing to a topic delivers every event within it. You can filter on the event field in your receiving system.
Can one webhook post to several Slack channels?
No. A Slack incoming webhook posts to a single channel. Create a separate incoming webhook in Slack and a separate webhook in Electric for each channel.
I filled in the form and it failed without telling me why.
Two things cause this. Check how many webhooks you already have, since each organization is limited to 20 and the count appears above the list. Also check that the name is not already in use, because webhook names must be unique within your organization. Neither of these is named in the error message.
Please contact our team at support@electric.ai if you have any questions or need any additional information with setting up your webhooks.