Proposal: Webhooks

[bitmotivator]

Abstract

Currently, there is no standard way for a system to dynamically update another system when a DMP changes. We should implement webhooks to make this possible.

Proposal

We should create webhooks as part of this specification for the following events:

• DMP created
• DMP updated
• DMP deleted

The payload for these events should contain a DMPWithID object. It should also contain an event ID the receiving system can use for deduplication and it should also contain an event timestamp for correct ordering of events.

OpenAPI supports this out of the box.

Out of scope

For this proposal, out of scope are:

1. Authentication of webhook requests
2. Automatic webhook registration

In other words, the goal is to provide a standard way to receive events from DMP tools.

[vaidap]

We'd find this very useful for our RSpace - DMP integrations! Our basic use case would involve automatically updating the local DMP that was imported into RSpace with the latest version from the DMP tool.

[bofstein]

I support having a standard protocol for this, though I would note the work to implement them on each tool may mean it doesn't get added at the same time as supporting the rest of the spec, and we'll need to make sure that's clear.

[andreadavanzo]

We already implemented this feature. More than happy to share the code and the standard we adopted.

[TomMiksa]

How do we proceed here?

[TomMiksa]

@dtziotzios @andreadavanzo do you have any specific preferences on how to do this? Do we use Notify protocol? Does this imply for us having a new endpoint and taxonomy of events? Or something else?

[andreadavanzo]

Hi all, here is what we built https://github.com/dmpsee/standard
We already developed a sustainable PHP/NGINX implementation: https://github.com/dmpsee/vaquita
More than happy to give mode details after IDW25

2026-02-10: Here is the updated link https://github.com/dmpsee/specification

[TomMiksa]

What is the impact on the design of our API? Do we need to specify extra endpoints?
How does this align, if at all, with COAR Notify and W3C Linked Data Notifications?

I don't want to ignore notifications in the design of our API, but I still don't understand whether there is any specific standard/recommendation to reuse, because the community is going to use it more extensively, or if we just have to come up with our own interpretation of the notifications.

[vknaisl]

I’m in favor of letting users define their own HTTP requests for different events. It’s probably the most flexible way to do it since every tool has different needs.

Regarding the COAR Notify discussion from the last meeting. I’m not sure how difficult it would be to implement. Doesn't that mean we would have to support JSON-LD? I'm curious if we are ready for that.

[paulwalk]

Caveat: I am one of the COAR Notify PIs (and coincidentally one of the original co-authors of the DMP-Common spec).

I think COAR Notify is a potentially very good fit for this. Support for it is growing in the repository platforms. Although we have initially focussed on use-cases related to peer-review and endorsement, we are starting to see implementations in use cases such as research evaluation, evidence gathering etc.

Although Notify does use JSON-LD payloads (as per the WC3 LDN spec), in practice this is just processed as ordinary JSON by every implementation I have seen so far.

I'm happy to discuss this any time!

[TomMiksa]

I’m in favor of letting users define their own HTTP requests for different events. It’s probably the most flexible way to do it since every tool has different needs.

@vknaisl: What do you mean by "users"? Do you mean different tool providers? Are you saying webhooks should be out of scope for the common API?

[vknaisl]

@vknaisl: What do you mean by "users"? Do you mean different tool providers? Are you saying webhooks should be out of scope for the common API?

By "users" I mean the community that will implement our specification — i.e. the various DMP tool providers.

Regarding COAR Notify, I'd prefer to wait and learn from your experience with it first before we decide anything here.

My overall take: I wouldn't include webhooks in the spec at this stage. I'd rather let concrete use cases crystallize and then standardize based on those.