Webhooks not working

[JuiceyBrucey]

Hi,
Found the REST API plugin file as instructed and have a release version of:
<Version>7.2.0.0</Version>

Just some additional information: I have several custom plugins running and they all work perfectly. This is the only one where I have encountered this issue.

I have tried using swagger and find it very frustrating as it redirects by adding the port number after the NGROK URL which results in an error. So I just use CURL and dont have this issue. It does not redirect and I can see the result of the request. I can set CURL to allow redirect, but I dont think that is going to help as the request has already been actioned and the redirect is just to confirm it by taking to another page.

I also tried using the wrong API Key for this user and all the other plugins still worked, but this one failed.

I am going to disable custom plugins and see what happens.
Thank you for all of your help.
Cheers

[JuiceyBrucey]

Is it possible that there is some permission that this user does not have set that could be obstructing this?
Cheers

[SBarnes]

The other thing you could try is creating a fresh demo database and pointing the api at that and see if that works at least from that you will know if it is unique to one database or not.

I would also advise keeping ngrok out of the equation until this gets resolved.

[SBarnes]

Found the REST API plugin file as instructed and have a release version of:
<Version>7.2.0.0</Version>

Can you confirm the version from the zip file is the above and not 7.2.1.0?

What actual Http status response code are you getting?

Are you running things as the self hosted service or under IIS?

Is it possible that there is some permission that this user does not have set that could be obstructing this?

Yes, but I doubt that is your issue that is controlled under System Settings -> Staff Configuration -> REST API but if the default permission is set to allow for the group that user you are using then everything should get through

[Mike.Sheen]

"If I were troubleshooting this, the first thing I would do is disable that plugin and try again."
Same thing happened.

Ah. You didn't restart the API service after disabling the plugin. If you did, you cannot possibly get the same error. You may get a similar error for a different plugin, but there is no way you could get it for the same plugin once disabled - unless of course your API is pointed to a different database to the one you're disabling plugins in.

[Mike.Sheen]

After all the effort you guys are putting in to help with this question, I really hope it is not something obvious that I have missed. Gonne feel pretty stupid if it is LOL.

Troubleshooting 101 is to start with known goods. No custom plugins or anything.

This is what I have done, and I suggest you do the same - until you have done these steps, I wouldn't go any futher.

1. Create a new demo database
2. Enable the REST API in that database and save it.
3. Configure the API service to point to that database
4. Start the service.
5. Open Postman, perform a GET on /auth?username=Admin&password=password
6. In Postman, perform a POST on Webhooks/Subscribers with the raw json body { "Name": "test999", "IsEnabled": true}
7. You'll get a 201 Created. Postman will have automatically put the ss-id cookie returned from step 5 into the POST request.

We need to know you can do the above before anything else.

"Would be good if you could show the whole raw request."
Sent values:
https://*****.ngrok.io/Webhooks/Subscribers/

$headerArr = array(
'Accept'=>'application/json',
'jiwa-stateful'=>'false',
'Authorization: Bearer '.JIWA_API_KEY,
"ss-id:".$this->JIWA_SESS_ID
);

curl_setopt($this->CURL_OBJ, CURLOPT_POSTFIELDS, "Name=".$SUBSCRIBER_NAME."&IsEnabled=true&apikey=".JIWA_API_KEY);

Returned reply header:
array(37) {
["url"]=>
string(47) "https://7ct27hqz.ngrok.io/Webhooks/Subscribers/"
["content_type"]=>
string(31) "application/json; charset=utf-8"
["http_code"]=>
int(200)
["header_size"]=>
int(342)
["request_size"]=>
int(1041)
etc etc

Reply body:
array(2) {
["Results"]=>
array(0) {
}
["Meta"]=>
array(0) {
}
}

That's not what is meant by the raw request. Your PHP isn't going to help me here, as I don't know what's in your variables such as JIWA_SESS_ID, or if they are valid.

What I meant was the raw HTTP request - it looks like this for a POST on /Webhooks/Subscribers using a cookied auth ss-id:

RawRequest.png (12.13 KiB) Viewed 1233 times

This is what is actually sent over the wire - and this removes any ambiguity or assumptions about what is being sent. If you don't know how to do this, It would be a good exercise to find out how as often with troubleshooting API's you'll be asked for the raw request, or you'll need to look at it to work out what is REALLY being sent.

[Mike.Sheen]

Is it possible that there is some permission that this user does not have set that could be obstructing this?
Cheers

Unlikely - A 403 would indicate user permissions, not a 401. A 401 means you're not authenticated - and checks that the user is authenticated happens well before checks if the user has permissions to the route.

[JuiceyBrucey]

Thanks again for all your help.
I am going to work my way through your answers one at a time.
I have spotted one potential inconsistency with versions of the REST API.
When I drill down into the JiwaAPI.zip file in this file:
Plugin REST API.xml
I get <Version>7.2.0.0</Version>

But when I look at the version information in the JIWA client, under REST API I get version: 7.2.1.0

I know this has been mentioned, but maybe I missed it.
Could this pose a problem?
Thank you

[Mike.Sheen]

When I drill down into the JiwaAPI.zip file in this file:
Plugin REST API.xml
I get <Version>7.2.0.0</Version>

But when I look at the version information in the JIWA client, under REST API I get version: 7.2.1.0

I know this has been mentioned, but maybe I missed it.
Could this pose a problem?

What we use is whatever is in the plugin of the database you're operating on.

We don't use what's in the JiwaAPI.zip file, but it should be 7.2.1.x if you're using Jiwa 7.2.1.

Just so we're clear, it's the version on the Plugin Maintenance form when looking at the REST API plugin

It should be at least 7.2.1.0.

If you install a Service Release (SR), we update the Plugin REST API.xml inside the JiwaAPI.zip file, but you have to extract that and use the Import tool on the Utilities tab of the Plugin Maintenance form to get that updated plugin into whatever databases you need. Once you do that, you need to save the plugin maintenance record and then restart your API service.

I don't see the how the plugin version would be causing your specific issue, however.

If you're not willing to do the "known goods" test and test using a new demo database, then the following steps are what I would do next.

1. Rename the Views folder in the Jiwa installation folder
2. Disable the plugin '1 - Performance Metrics'
3. Restart the Jiwa REST API service
4. Perform your request to POST on /Webhooks/Subscribers again. You won't get a HTTPCompileException relating to the plugin '1 - Performance Metrics' anymore. You may get a different error, probably a 401 because that route requires authentication.

As all the Webhook routes require authentication, you should also have a problem with a GET on Webhooks/Subscribers also - so you can test that using a web browser:
1. Visit /auth?username=Admin&password=password

2. Visit /Webhooks/Subscribers

What do you see when you do that?

What I see when I try visiting /Webhooks/Subscribers and not authenticated is this:

And that's because I haven't deleted or renamed the Views folder and the API is trying to be nice and redirect my browser to a razor view with a login dialog because it knows you're not authenticated and it knows you're using a web browser, so it's trying to be helpful - but some other issue with that environment is throwing the HTTPCompile exception - but it'll only happen when using a browser.

Why your PHP code is getting this is probably because your user agent string is making your request look like a web browser - but I can only guess that because I've not seen your raw request.

[JuiceyBrucey]

Hi,
I have followed the instructions in this last post but still not getting a subscriber created.
I have used the browser to authenticate as suggested, no problems there, but it offered a link to redirect rather than trying to redirect automatically.
I have changed the View folder, restarted the services, and run the script again.
I disabled the Performance Metrics plugin and restarted the services.

But am still getting http 200, with the following returned data:
array(2) {
["Results"]=>
array(0) {
}
["Meta"]=>
array(0) {
}
}

Authentication does not seem to be the problem, or redirect when I am using CURL or the browser. I may have mislead you by showing the error message that came from not properly authenticating.

not sure if related, but tried to do a inventory update using Inventory/{INVENTORY_ID} and could not get it to update an item either.
All custom plugins work fine, no problem at all.
I will work my way through the other suggestions and get back to you.
Thank you very much for a very detailed reply.
Cheers