InsightIDR Webhook Option

Good day!

Does anyone manage to find a way to use Webhook option in InsightIDR?

From the documentation, the webhook option is only available for InsightOps, any alternative way to do this in InsightIDR? We are trying to integrate an event source which is capable of using the Webhook option just that I cant find any details from InsightIDR side on how to receive such data from source.


I have been wanting to do a webhook into a Microsoft teams channel. I understand that is not working and I did get an email recently from support that did indicate they were going to make this an enhancement and basically get it working.

1 Like

We are referring to two different Webhook methods here @nowel is referencing this HTTP POST | InsightOps Documentation I believe which is a data ingestion method for log search whereas @pete_jacob I want to say you are referring to Universal Webhook | InsightIDR Documentation which is a data exporter option for alerts.

@nowel for the Data ingestion method its possible to get this working without InsightOps. All you need is a Log token, its possible to create a log in log search via the API shown here POST Log | InsightOps Documentation

the response from this POST request would return the log token. Which could then be used to send data to that webhook.

However this does come with an important caveat, the data sent via webhook is not sent through the IDR pipeline, meaning data cannot be custom parsed, nor can it be used for detections or community threats. Effectively the data is sent straight to log search, which would then allow you to build custom alerts and dashboards as needed.


1 Like

Hi David,

Thanks for the information! This looks like the go-to way to achieve what I want.

Just a question though, how do i get the logsets_info id?

I took a look at the reference you have shared:

And seems like the calls need that ID which I don’t have any idea where to get at first.

From what I know (provided it is the same thing to what I understand), logset id can be located by going to the Log Search then ticking on a specific log set. From there the log set ID can be located at the link OR if you have leverage the used of an agent to read additional logs locating the log set ID is fairly easy. This is all true only when there exist a corresponding event source entry or log set entry in the Log Search.

So in general the process would look like:

  1. Create a new log set for my account. Ref: POST logset | InsightOps Documentation
  2. Generate or get that token.

    Tested this on my current log set from additional agent logs and this works fine provided item #1 is present.

  3. Configure event source to send logs to my IDR via webhook

At the end, seems like creating a logset is the first thing to do. Can this be done in InsightIDR?
The reference here: POST logset | InsightOps Documentation
though for InsightOps, am hoping this is applicable in InsightIDR but the sample call from the reference is asking me to provide that logset log_info id when I am trying to create one myself :sweat_smile:

Hope to get your help on this.


Hi Knowell,

you are correct you can create a logset using that POST method with just InsightIDR, as the Rest API is shared between InsightIDR and InsightOps anything you see documented in the InsightOps docs is also possible in InsightIDR. We just haven’t documented it all under the IDR pages as I mentioned sending data through this method does not pass through our detection engine and is more of an Operational use case, something our InsightOps customers would typically want.

One thing to note you could also add a log to an existing logset (by calling a GET on all logsets GET Logsets | InsightOps Documentation) if you wanted it to populate under one that has been already created such as the Raw Logs logset. I wouldn’t recommend this however as it may be confusing as to why you don’t see the new log listed when you navigate to the custom parser for example. As I mentioned these manually created logs bypass the IDR pipelines and therefore cannot be custom parsed. So a new unique logset would be the preferred method.