Skip to main content

It might seem like a silly question, but I am finding it impossible to get webhooks to work without going via Zapier. I have tried using a Google Scripts web service and have created my own REST service running locally (I’ve set up port forwarding and have tested this outside of InSided). I have managed to register the services correctly (Google Scripts and my own test REST service). Registering fails if you make mistakes with event names, etc. But when I try to trigger the service (using the question.Liked event, for example), it is never even attempted. However, setting this up via Zapier takes seconds and does work. Strangely, it doesn’t seem to be logged as configured in the same way as those using the API to set up. You can’t see it when you use the https://api2-eu-west-1.insided.com/v2/webhooks endpoint….as you can with the events subscribed to using the API. The configurations you can see are set up, do not work.

The documentation on webhooks is pretty limited and there appears to be no way to trace what might be happening at the InSided side. I suspect that there is something left out of the documentation (or something I haven’t seen) which can help fix this/answer this. Any ideas?

They should. I’ve never used them with anything other than Zapier, but I use Postman to subscribe my Zap URL to the webhook. 

I believe we used them at a previous company without Zapier, but I’m not positive. 

It looks like I was going down the wrong path here. I have found my issue. Setting up the subscription is fine. There is no issue there. I ended up switching between our sandbox and prod environment trying different scenarios. I did this because when we first started using Federated Search, it wasn’t switched on in our sandbox environment, so I immediately jumped to that as a possible cause when trying to work out what was wrong here. I ended up losing where I was, which led to my thinking that the events weren’t being called.

Once I got beyond that, I found the issue. It turns out that the issue is what we were receiving. It is not as easy as it could be to debug Google Scripts. So I had to hack around for a while to find this. It turns out that the event was being called, but it caused the script to fail because the JSON that is returned is not what you are led to believe from the documentation. 

The documentation states that you will receive this for the IdentityAccess.UserLoggedIn event…..
 

{
    "userId": 12,
    "date": "2019-10-10T16:07:21+02:00"
}

What you actually receive is this….

{"IdentityAccess.UserLoggedIn":{
"date":"2024-01-31T17:46:08+01:00",
"userId":11.0}
}

So my code was expecting to find userId and date at the root of the JSON. It wasn’t there.

Could I request that the admin user interface enables us to see logs specific to our environments? With logs, I could have quickly gone through them and removed the first issue I had. Can I also request that the documentation is updated to let us know exactly what the events will return? At the moment, the expectation is that the events will return the data on the root of the JSON.  

 

Hi @rhall 👋,

Thanks for pointing this out to us! We’ll get the documentation updated for you to show an accurate response example.

I would advise creating an idea for your feature request around logs, such as where you would like this to be displayed and what specifically would be most helpful for these logs to display. Thanks again for this valuable feedback!

Reply


Terms & ConditionsCookie settings