COAR Notify Protocol Explained

COAR Notify (formally the COAR Notify Initiative) is a communication protocol that lets repositories, preprint servers, overlay journals, and peer-review services exchange structured, machine-readable notifications about a research output — a new deposit, a completed review, an endorsement, a link to a related resource — without requiring a bespoke, point-to-point integration between every pair of systems. It is built entirely on existing W3C web standards rather than a bespoke scholarly-communication protocol, which is the design choice that most distinguishes it from earlier repository interoperability approaches.

This guide is a technical deep-dive into the protocol itself: its message format, its notification patterns, how an exchange actually works end to end, and which platforms have implemented it. For the broader initiative COAR Notify grew out of — the 2017 Next Generation Repositories (NGR) report and its eleven target behaviours — see CASRAI’s COAR NGR guide, which covers that initiative’s origin, working group, and full behavioural scope. This page assumes that context and does not repeat it; it exists because NGR’s “notification and awareness” behaviour is described there only at the level of a paragraph, and the protocol that actually implements it deserves its own reference.

What problem COAR Notify solves

Institutional and disciplinary repositories built around OAI-PMH harvesting are good at exposing metadata for indexing, but OAI-PMH has no native way to tell a repository that something happened to one of its items elsewhere on the web — that an overlay journal accepted a preprint for review, that a reviewer endorsed a dataset, that a related version was deposited somewhere else. Historically, connecting a repository to an external review or evaluation service meant a custom API integration built and maintained per platform pair. COAR Notify replaces that with a shared, decentralized notification layer: any COAR Notify-compliant sender can notify any COAR Notify-compliant receiver, and the receiving system decides what to do with the notification (display it, act on it, ignore it).

Technical foundation: LDN and ActivityStreams 2.0

COAR Notify is not a new wire protocol invented for scholarly communication. It is a documented profile — a set of constraints and conventions — layered on top of two existing W3C Recommendations:

W3C Linked Data Notifications (LDN) supplies the transport mechanism: how a sender discovers where to deliver a notification (an LDN “inbox” URL, discoverable from a resource via HTTP Link headers or embedded metadata) and how that delivery happens (an HTTP POST of a JSON-LD document to the inbox).
Activity Streams 2.0 (AS2) supplies the payload vocabulary: the JSON-LD structure used to describe “who did what to which object,” which COAR Notify reuses rather than inventing a parallel scholarly-notification vocabulary. Every COAR Notify payload is required to be a valid AS2 activity, and every payload’s @context must include the AS2 namespace (https://www.w3.org/ns/activitystreams), with COAR Notify adding a small number of its own vocabulary extensions for scholarly-specific properties the base AS2 vocabulary doesn’t cover.

The practical effect is that a COAR Notify message is a JSON-LD document any AS2-aware or LDN-aware tooling can partially parse even without COAR-specific logic, and that a repository or service only has to implement one inbox endpoint to receive notifications from any conformant sender in the ecosystem — not a separate integration per partner.

Notification patterns

COAR Notify calls its standardised payload shapes patterns. Each pattern is a specific, named AS2 activity type with defined required properties, documented in the protocol’s specification and organized into two broad families:

Announcement patterns

Used when a sender is announcing that something already exists or has already happened, referencing the resource it concerns:

Announce Endorsement — a resource has received a formal endorsement (for example, from an overlay-journal editorial process).
Announce Review — a review of a resource has been completed and is available.
Announce Relationship — a resource is related to another resource (a new version, a dataset tied to an article, and similar links).
Announce Ingest — a resource has been ingested into a repository or archive.
Announce Service Result — the outcome of some other service action on a resource.

Request patterns

Used when a sender is asking a receiving service to take an action, expressed as an AS2 Offer activity:

Request Endorsement — ask a service to formally endorse a resource.
Request Review — ask a service (an overlay journal or review platform) to review a resource.
Request Ingest — ask a repository to ingest a resource, or a copy of it.

Because every pattern is a documented AS2 activity type with a fixed required shape, a receiving system can programmatically distinguish “someone is telling me a review happened” (Announce Review) from “someone wants me to review something” (Request Review) purely from the payload structure, without any out-of-band coordination between the two platforms’ engineering teams.

How a notification exchange actually works

A representative flow, combining an overlay-journal review request with the resulting announcement, looks like this:

A researcher deposits a preprint in a COAR Notify-enabled repository or preprint server.
The depositor (or the repository, on the depositor’s behalf) sends a Request Review notification to an overlay journal or independent peer-review service’s LDN inbox, referencing the preprint’s URI.
The review service accepts or declines the request; if it accepts and later completes a review, it sends an Announce Review notification back to the repository’s inbox, referencing both the review and the original resource.
The repository, on receiving that notification, can display the review alongside the preprint, link out to it, or pass it into a connected CRIS — the protocol only standardises the exchange, not what either side does with the information afterward.

The same pattern generalises to endorsements, dataset-to-article relationship links, and ingest requests between repositories — the mechanics (discover the inbox, POST an AS2 activity of the right pattern type) stay identical across all of them.

Real-world adopters and implementations

COAR Notify moved from specification to production use across several platforms. As of 2026, publicly documented adopters and in-progress implementations include:

HAL (the French national open archive) and Episciences, a platform for diamond open-access overlay journals that layers editorial review on top of repositories including arXiv, Zenodo, HAL, and CWI — Episciences uses COAR Notify (alongside the related Signposting the Scholarly Web conventions) to exchange information with compatible repositories.
Peer Community In (PCI) and PREreview, independent, repository-agnostic peer-review platforms that review preprints hosted elsewhere.
bioRxiv, among preprint servers with reported COAR Notify integration.
DSpace, the widely-deployed open-source repository platform, added native COAR Notify support starting with its 7.x line, extending into DSpace 8 — a significant adoption driver given how many institutional repositories run DSpace.
Dataverse, which documents an LDN-based notification API in its own developer guides.
Additional platforms reported to have implementations underway or in production include Open Preprint Systems (OPS), Kotahi, Invenio, EPrints, PubPub, and the peer-review platform used by eLife.

The pattern across nearly all of these adopters is the same: they are either overlay-review services that need to talk to repositories they don’t control, or repository platforms that need to talk to review services they don’t control. That many-to-many problem is precisely what COAR Notify’s decentralized, standards-based design is meant to solve, rather than every pair negotiating a custom integration.

COAR Notify and COAR NGR: how the two relate

It’s worth being precise about the relationship, since the two are easy to conflate. COAR’s Next Generation Repositories (NGR) report, published in 2017, is a behavioural roadmap: it names eleven capabilities repositories should support (discovery, text/data mining support, evaluation interoperability, notification and awareness, consistent identifier use, and others) without prescribing specific protocols for most of them. COAR Notify is the concrete protocol implementation of exactly one of those eleven behaviours — notification and awareness — developed as its own initiative with dedicated specification work, a public roadmap, and (per COAR’s own published materials) multi-year funding support. In short: NGR is the “why” and the target behaviour; COAR Notify is the “how,” built years later, for that one behaviour specifically. A repository or CRIS team evaluating NGR alignment more broadly should read the NGR guide; a team specifically implementing or evaluating notification/overlay-review interoperability should use this page and COAR Notify’s own specification.

Why this matters for CRIS teams and research administrators

Repository and CRIS procurement — COAR Notify support (or a stated roadmap for it) is now a legitimate, specific line item to ask vendors about, rather than the vaguer “NGR alignment” framing, especially for institutions running or evaluating DSpace-based repositories.
Overlay-journal and diamond open-access strategy — institutions or consortia considering repository-hosted, editorially-independent review models (in the spirit of Episciences or PCI) need COAR Notify-capable infrastructure on the repository side for that model to function without custom integration work.
Research information flow — because notifications are structured, machine-actionable events rather than emails or manual updates, a CRIS that can consume them can keep researcher profiles and output records current (a review completed, an endorsement received) without manual data entry, in the same interoperability spirit as ORCID and Crossref event data.
Standards literacy for vendor conversations — understanding that COAR Notify is “LDN plus ActivityStreams 2.0, not a bespoke protocol” helps research-administration and IT staff evaluate a vendor’s real implementation depth rather than taking a marketing claim of “COAR Notify compatible” at face value.

Frequently asked questions

Is COAR Notify the same thing as COAR NGR?

No. NGR is the broader 2017 behavioural roadmap for repositories; COAR Notify is the specific protocol that implements one of NGR’s target behaviours (notification and awareness). See the section above for how they relate, and CASRAI’s separate COAR NGR guide for the initiative-level overview.

Does COAR Notify replace OAI-PMH?

No. OAI-PMH remains a metadata-harvesting protocol for bulk discovery; COAR Notify is an event-notification protocol for point-in-time messages between systems (a review happened, an endorsement was given). Most repositories running COAR Notify continue to support OAI-PMH alongside it for harvesting.

Do I need to understand ActivityStreams and JSON-LD to evaluate a COAR Notify implementation?

Not in depth, but knowing that the payload is a standard AS2 JSON-LD activity (not a proprietary format) is useful when asking a vendor how portable or standards-conformant their implementation actually is.

Which repository platforms support COAR Notify today?

DSpace has the most mature, widely-deployed support (from its 7.x line onward). Dataverse documents LDN-based notification support in its own guides. Several other platforms have implementations reported as in progress; check the platform’s own release notes for current status before assuming support, since this is an actively developing area.

What is an LDN inbox?

An LDN inbox is simply an HTTP endpoint associated with a resource, discoverable via a Link header or embedded metadata, that accepts POSTed notifications about that resource. It’s the delivery mechanism COAR Notify reuses from the underlying W3C LDN standard rather than defining its own.