[Webhook] Webhook registered at API end without storing details in DB

[touhidurabir]

Feedback from a journal

I’m trying to register a journal in iThenticate, but I keep getting the error:

iThenticate webhook not configured for context id 1

The webhook API key is correct.

When I attempt to register it, I receive the following response:

{"success":false,"status":409,"code":"CONFLICT","reference":"REFERENCE_ID","debug_message":"A webhook with the same URL already exists. Either update or delete the existing webhook.","message":"A webhook with the same URL already exists. Either update or delete the existing webhook."}
[17-Feb-2026 08:46:22 Europe/London] unable to complete the iThenticate webhook registration for context id 1

If I try to update the webhook, I get the same error.

When I run the validation command, it still says the iThenticate webhook is not configured for context id 1.

Listing the configured webhooks returns:

 ID   Path             Webhook ID       Configured

 1    context-path    Not configured   No

Could you please let me know if you have any idea how to fix this issue?

This present a possible bug where the plugin webhook has been registered but the returned webhook data has not been saved in DB . As a result, next time plugin will again try to register webhook as it's details not available in the DB but with same url webhook registration attempt cause to fail with 409(Conflict) response .

NOTE that it is still not verified that it's a bug of the plugin system or some other factor are in play here to cause such situation

This also present the possibility of enhance the Webook CLI tool with more options . Right now the webhook cli tool only take consideration of wehbook details that is present for the context in the database . But as iThenticate API URL/KEY is also available to check the webhook status/list/update/delete using the API creds .

To enhance the webhook CLI tool, add following ability

1. list based on the api creds only
2. update/delete based on api creds only

PRs

3.4 --> #104
3.5/main --> #103

[asmecher]

Passed this back to the user who reported it (via MatterMost) for QA; until then we shouldn't merge as we haven't been able to reproduce the initial problem (or therefore test the solution).