Webhooks for events (checkin, checkout, expiration, ...)

[hixair]

Server (please complete the following information):

• Snipe-IT Version 4.6.5
• OS: Ubuntu
• Web Server: nginx
• PHP Version 7

Is your feature request related to a problem? Please describe. Using web hooks and various API calls, I have setup an integromat scenario where assets are automatically checked out to the user who enrolled the Apple Device. It works extremely well and relies on the webhook from our MDM to get the serial number and user id.

I would like to do the same when an asset is checked in, as it should be removed from our MDM and ready for another enrolment. I cannot currently easily call the Snipe-IT API to get a list of the last checked-in assets for example.

Describe the solution you'd like The slack menu in settings should be called "Webhooks". You should be able to configure multiple webhooks to post to, and choose for each what type of data to post to the webhook : slack alert, json for checked-in assets, json for checked-out asset, json for expiring licences/warranties/loans, ...

Describe alternatives you've considered Alternative would be to develop a proper tool to handle the APIs on both sides, but in our work environnement, we have to deal with tools such as integromat and zapier.

Thanks !!

[coutueric]

We would also like to be able to register webhooks to certain events. Our specific case would be to bind Snipe-IT licence assignation to trigger a webhook. It would give us a way to trigger automation.

Thanks!

[hixair]

To elaborate on what we currently do with snipe’s API : We want to continuously simplify our onboarding/outboarding/inventory processes and have as many automations as possible. We are pretty close to the « zero touch » IT trend that is rising with the Apple devices in the entreprise. We have a pile of reused and new computers. When a new recruit joins the company, we hand them out a laptop, a phone, etc. User opens the laptop and then has to use his directory credentials to do the initial setup/enrollment. The enrollment completion triggers a webhook in our MDM that starts an Integromat scenario. Integromat receives informations about the enrollment as a Json containing the device’s serial number, login of the enrolling user, ... The Integromat scenario then polls snipe-it’s API to get the ids related to the serial number and user login and makes a final call to check the device out of the inventory for the proper user and alerts the team through Slack. We used to do this by hand, sometimes we forgot, even with notifications to slack. Now the process is automated and almost perfect.

When a user leaves the company or we upgrade his unit, we have to check his device in, remove it from our MDM, restore it’s system, etc.

Being able to select custom webhooks for events could help us automate the process the other way around and for example, checking the device in would trigger a webhook which then would help us establish a scenario where the device is removed from our MDM, using it’s API.

Some other tools we use, choses to have a webhook category in the settings, from which you can add a new webhook (it adds a new line to the page) with a drop down from which you can select the event, then the address of the webhook, and finally a button to edit some settings depending on the event (for example editing the message template for the slack alert event, selecting the attributes available in the json, ...).

I feel that not all events from snipe-it should have a webhook right away and the one to start with should be :

• asset / consumable / accessory checkin
• asset / consumable / accessory checkout
• asset status changed
• expected checkin date expiring
• warranty expiring
• EOL expiring
• warranty expiring
• new person grabbed from the directory
• new asset acceptance signed off

This should allow to cover a lot of automation cases where we want to update several tools, notify the proper persons about what is going on, etc.

Thanks !

[stale[bot]]

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

[hixair]

It is ! Thanks !

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[stale[bot]]

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

[hixair]

It is.

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[kallusakar]

Greetings everyone, we also found ourselves needing webhook functionality. Mainly for the check-in(out), status changes events etc. Is there still some demand for this from the community? Maybe we could pull our resources, cooperate and implement the functionality together.

Thanks!

[bricelabelle]

We would love the webhooks to fire in more cases, specifically when checking out a license to an asset. We've put a custom URL in place of the slack one so that when we checkout licenses we can kick off a process that will actually install the apps on the devices as well. The problem is that the webhook only fires when a license is checked in. I don't have a great grasp on php but from what I can tell the logging and notifications in snipe go hand in hand. I believe the logCheckout and logCheckin functions in the /app/models/Loggable.php file are what do this. In these functions, you can tell that it's checking for whether or not the asset/license is checked in or out to a location, asset, or user and then it only sends the notification if it's checked in or out to a user. I just don't know how to change it so it sends the notification no matter what it's checked out to. Hopefully this at least puts someone on the right track.

[hixair]

We would love the webhooks to fire in more cases, specifically when checking out a license to an asset. We've put a custom URL in place of the slack one so that when we checkout licenses we can kick off a process that will actually install the apps on the devices as well.

Oh yes !! I need this ^ too !

[snipe]

This is already on deck for after v5.0 comes out

[hixair]

👍🏻👌🏻❤️

[clmaliwat]

Looking forward to this. I too am looking forward to an integration with my MDM when there's a checkin/checkout of a machine.

[snipe]

Can whoever is interested in this please provide some rough examples of what kind of payloads you'd be interested in? Trying to plan this out with as many use-cases as we can here.

[hixair]

Ok we should start drawing a list of useful events we would like some webhooks for. To make it simple I would love to have a webhook for check in and checkout of devices. Also for checkout of licences to have the MDM start the installation of related packages to the devices, pass the serial code if any to sérialize the software, ...

If I get back to my initial list, I can develop the use case if you need me to and maybe everyone could contribute with events that they need ?

• asset / consumable / accessory / licence checkin
• asset / consumable / accessory / licence checkout
• asset status changed
• expected checkin date expiring
• warranty expiring
• EOL expiring
• warranty expiring
• new person grabbed from the directory
• new asset acceptance signed off
• ...

[snipe]

That's very helpful, thank you! I'm wondering about the best ways to actually handle the payloads themselves. I'd guess a text box for each event, one with a webhook endpoint, another with a textbox for a formatted response with % placeholders based on the type of data the event could potentially contain, like:

{
    "random_thing_1":"webhook endpoint specific value 1",
    "random_thing_2":"webhook endpoint specific value 2",
    "random_thing_3":"webhook endpoint specific value 3",
    "webhook_asset_tag_fieldname":"%asset_tag%",
}

[snipe]

I also worry about how to sanitize this data TBH. And how to confirm that a bad actor couldn't send bad XML to an unsuspecting endpoint that isn't theirs, effectively using Snipe-IT to attack someone else.

[hixair]

I am far from an expert but on other tools, i usually see a text field where you can input your webhook address and then a dropdown to select the event. Then you press add and build a list of webhooks you send info to, when triggered by the given event. You can remove a line or add at will.

I will see this in snipe’s preferences instead of the slack item, and from there you could set your slack webhook as well with a slack events list to choose from.

Finally every tool I used usually send Json and the receiving part has to deal with what is inside the post.

I am not really worried about your concern attacking a host through snipe-it (if i understood well) as people are not supposed to share the urls a webhook can post to.

[snipe]

Then you press add and build a list of webhooks you send info to, when triggered by the given event. You can remove a line or add at will.

Of course, but different webhooks will have different payloads, and there's no way for us to know what payload you want sent to an arbitrary webhook.

I will see this in snipe’s preferences instead of the slack item, and from there you could set your slack webhook as well with a slack events list to choose from.

This would be a separate webhook section and wouldn't necessarily relate to slack. The built-in slack stuff would remain, as for most people who don't need/want webhook integration, this is a much simpler approach.

I am not really worried about your concern attacking a host through snipe-it (if i understood well) as people are not supposed to share the urls a webhook can post to.

I am. What people are supposed to do and what they actually do are often different. An angry ex-employee who still has webhook info for a company they used to work for, etc. I don't want Snipe-IT, self-hosted or our platform, weaponized.

[bricelabelle]

The way I kind of envisioned this working for payloads would be similar to what we already get from the API. So, for example, if you checked out an asset the payload sent would be the same as what is found at the /hardware/:id endpoint. If you checked out a license to an asset you would get the payloads from both /hardware/:id and /licenses/:id in a single payload. The same pattern could be followed for checking out consumables or accessories. In fact, you could set up a single webhook so that anytime anything is checked in or out it sends the same payload you would get from using the API to view that item. To make this customizable you could have a dropdown box where you can choose an action to trigger the webhook such as "warranty expiring", a text box to enter the payload you want in the format "/hardware/:id" since in this case we want the info from the asset whose warranty is expiring, then in the last box you enter a URL to send the payload to.

One feature we think would be really cool is the ability to add a menu item to the "Actions" menu on the View Asset page which could be used to trigger a specific webhook. For example, we make a custom menu item called "Send Restart Command" and that kicks off a webhook that tells our MDM to send a restart command to that device. In that case, we would use the same format as I mentioned above where we would send the payload found at /hardware/:id for the page of the asset you are on.

[hixair]

Thank you it makes a lot of sense this way !

[stale[bot]]

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

[hixair]

It is !

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[renardeau]

Those webhooks sounds really nice. I especially like that idea of a webhook linked to an actions menu item. Would this webhook allow for a response to notify if the requested action was successfully executed?

[stale[bot]]

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

[nicholasmhughes]

Not stale!

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[friedpope]

Just wanted to ping this issue with my own feedback. We're possibly moving away from Slack soon to Teams and I'd like a way to push notifications over to that platform.

I'd like to suggest a more generic approach to webhooks than what people have been proposing. With some other APIs I've been working with the webhook subscription is setup using the API itself to create a subscription where a remote service will take a POST and respond with a 200, or whatever, in response. The format of the POSTs to the external system are predefined, in this case by Snipe-IT, with some simple JSON payload about the event. Leave it up to a glue service in between to connect Snipe to XYZ.

For additional protection against weaponizing this you can add some throttling, disable subscriptions after X number of 400/500s, and maybe add a user defined header token at subscription so the glue service can verify the validity of the POST.

[hixair]

Thanks !! That’s what I had in mind when I suggested replacing slack altogether with webhooks. As long as you can send a payload to a webhook it is really easy to setup in slack or any other system. And what would make it powerful would be the ability to select which event send a payload to which webhook :)

Le ven. 10 janv. 2020 à 02:14, friedpope notifications@github.com a écrit :

Just wanted to ping this issue with my own feedback. We're possibly moving away from Slack soon to Teams and I'd like a way to push notifications over to that platform.

I'd like to suggest a more generic approach to webhooks than what people have been proposing. With some other APIs I've been working with the webhook subscription is setup using the API itself to create a subscription where a remote service will take a POST and respond with a 200, or whatever, in response. The format of the POSTs to the external system are predefined, in this case by Snipe-IT, with some simple JSON payload about the event. Leave it up to a glue service in between to connect Snipe to XYZ.

For additional protection against weaponizing this you can add some throttling, disable subscriptions after X number of 400/500s, and maybe add a user defined header token at subscription so the glue service can verify the validity of the POST.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snipe/snipe-it/issues/6405?email_source=notifications&email_token=AAFVSBCBD372XAO7HNAPDRDQ47DV3A5CNFSM4GCFXUL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEISK2YI#issuecomment-572829025, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFVSBCD2ZU6PSLKINIMK4LQ47DV3ANCNFSM4GCFXULQ .

[fanuelsen]

We are also looking for something like this to trigger automation :)

[stale[bot]]

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

[hixair]

It is !!

Le dim. 12 avr. 2020 à 10:36, stale[bot] notifications@github.com a écrit :

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snipe/snipe-it/issues/6405#issuecomment-612582427, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFVSBAIQVIUVUL5RDIRNWTRMF4PTANCNFSM4GCFXULQ .

--

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[stale[bot]]

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

[hixair]

It is !

Le 12 juin 2020 à 09:28, stale[bot] notifications@github.com a écrit :

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snipe/snipe-it/issues/6405#issuecomment-643116837, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFVSBFFATJPLYQ5LSFQQBTRWHKJJANCNFSM4GCFXULQ.

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[mikedowler]

I'd also love to see webhooks available.
In relation to the security concerns raised by @snipe last year, I think they are valid. In general, anyone can post anything to a webhook. If that webhook is set up to trigger an action in another system (e.g. an update in an MDM record), then that action would appear to have been triggered by Snipe-IT even when it wasn't. We can't stop people creating and using insecure webhooks, but we can make it less likely that they will do this. One thought that I had was to only provide the absolute minimum essential information in the webhook. For example, you could simply provide a unique code, and have an API endpoint which can be queried (and which of course requires credentials) to obtain further information about the event that triggered the webhook. The idea would be to send the webhook to something like Jenkins. It would be up to the owner to configure this so that it ingests the webhook, and runs a script which queries the Snipe-IT API to obtain the additional information, and then uses that additional information to make further API calls to third-party systems. In this way, the most that a malicious actor could do would be to force the Jenkins to query the Snipe-IT API for the latest information.

[fanuelsen]

Yes! I totally agree with @mikedowler That would be a perfect solution for automating stuff.

[stale[bot]]

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

[danpoltawski]

Yes. Need this functionality is integrate with our workflows.

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[1random]

+1 for functionality

Will be very useful to integrate NetBox tool with Snipe IT Inventory tool

[RyanMorash]

Where I work full time we use Teams and would currently be unable to integrate the Slack specific webhooks there.
But where a more generic webhook implementation would be more useful is where I volunteer. We are a completely volunteer run organization and communicate using Discord. We are just starting to implement Snipe-IT and it would be great to be able to get alerts in our main communications hub.

[ella-ignition]

Any updates on this? v5 is out and it appears that webhooks haven't been added. We're considering starting to use Snipe but being able to update other management systems whenever a Snipe asset is edited is a super important part of our considerations.

As @mikedowler said, one option for increasing security would be to just include a few details like Asset ID, callback URL, timestamp. Personally I'd love to see a fully configurable webhook engine where endpoint, headers, and payload could be customized with variables. Being able to send encrypted auth headers would be really nice and help with the security concern quite a bit.

[bebeto-web]

Hi There, This thread still active ?, I would like to seek your help about the SnipeIT, which I can right a code and manipulate the trigger of the Action buttons (Checkin, Checkout, Update and Delete) to send a data in a 3rd party software system (send in our own database ) once the API was executed after button is triggered. BTW I'm a newbie in SnipeIT sorry for the inconvenience

[ghost]

any progress here? even being able to customize the data sent to slack would be helpful.

[hixair]

This is a big deal for us as it will allow a complete automation of our inventory and onboarding/offboarding.

On Wed, 24 Mar 2021 at 23:24, Chris P @.***> wrote:

any progress here?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snipe/snipe-it/issues/6405#issuecomment-806223976, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFVSBH44EIVRI2HJRWBJYLTFJRAVANCNFSM4GCFXULQ .

[jspc0]

+1 for the feature