Subscribers cannot be notified by topic

[atanas-todorov-assent]

I'm using novu-dotnet 0.6.0.

I could notify a subscriber by its id:

            var payload = new Dictionary<string, object>()
            {
                { "key1", "value1" },
                { "key2", "value2" }
            };

            var eventData = new Novu.Domain.Models.Events.EventCreateData()
            {
                EventName = "test-in-app",
                To = new Novu.Domain.Models.Events.EventTo()
                {
                    SubscriberId = "ca6f045a-668d-4232-b76e-f37acafc9eb6"
                },
                Payload = payload
            };

            var response = await novu.Event.Trigger(eventData);

But there is no way to trigger a notification by topic and notify all subscribers associated with that topic. The EventCreateData.To property is too limited, as it doesn't allow specifying a topic key. There is also no overload Trigger() method to support this.

However, if I directly use Novu API I can successfully associate a subscriber to a topic (topicA):

https://api.novu.co/v1/topics/topicA/subscribers

{
  "subscribers": ["ca6f045a-668d-4232-b76e-f37acafc9eb6"]
}

And then notify all subscribers (including the above one) associated with that topic:

https://api.novu.co/v1/events/trigger

{
  "name": "test-in-app",
  "to": [
    {
    "type": "Topic",
    "topicKey": "topicA"
    }
  ],
  "payload": {}
}

[atanas-todorov-assent]

Update:

It is possible. But the method is not called Trigger() - it's called Create()... And it uses the same parameter type as when a topic is created.

            var payload = new Dictionary<string, object>()
            {
                { "key1", "value1" },
                { "key2", "value2" }
            };

            var eventData = new Novu.Domain.Models.Events.TopicCreateData()
            {
                EventName = "test-in-app",
                To =
                [
                    new Novu.Domain.Models.Triggers.TopicTrigger(topicKey: "topicA")
                ],
                Payload = payload
            };

            var response = await novu.Event.Create(eventData);

I would suggest at least renaming Create() to Trigger() in IEventClient, as the current name can be misleading.

[vertigo7x]

Hi @atanas-todorov-assent !
Did you manage to send notifications to a topic with the code provided avove? I'm getting a 422 all the time with a work flow not found message inside the refit exception. It's annoying because there is no way to select a workflow to trigger.
My configuration is just API Key and novu API URL.
Am I missing something?

[toddb]

@atanas-todorov-assent @vertigo7x

If you checkout the README events, this method is the only with that did not have full compatability

There are multiple issues here (which I can help fix), but two main problems stand out:

---

1. Design Inconsistency

The Novu API follows more of an RPC-style design over HTTP, meaning it's verb-based and mixes Level 1 and Level 2 REST interfaces. For example, the EventClient resource is Level 1 because it uses POST with an action verb like trigger.

The C# client library, however, generally tries to treat all endpoints as if they follow Level 2 REST principles.

This leads to confusion in the EventClient. To add to the complexity, I’ve made some changes to the code as I took over the library, which haven’t been fully reconciled — hence the inconsistencies between Create and Trigger methods.

If you look at the EventClient interface, you’ll see it also handles bulk and broadcast operations — it’s a bit of a mess at the moment. All of these could be an overload.

Proposed Solution

We need to refactor the interface to use consistent, idiomatic C# overloads — while preserving backwards compatibility. Personally, I prefer using Create instead of Trigger since we’re conceptually dealing with a resource (REST-style), not an action (RPC-style). That said, I propose supporting both as aliases to improve developer usability.

All four variants (Create, Trigger, bulk, broadcast) should be implemented as overloads of a single method signature. That way, IDEs can provide better autocomplete.

---

2. Payload Issues

The payload on the event trigger has so many untyped options and the combinations needs to all be just right. The more this is coded/abstracted into the C# client IMHO the better. Although I think the better solution is a cleaner API with less polymorphism but this the leakage of a dynamic language implementation (hypermedia would help with a clearer interface at a machine level).

I notice that actor could have an upgrade to its longer form rather than just stringly subscriberId
I notice that tenant needs to be added (and there is the stringly form of identifier or the longer tenant version)

Proposed Solution

We need to work a little harder on the models and conditions of use. The main switching at the moment is on the to field. There are four options in v0.x and three in v2.x. The current implementation moves between two (topic and event).

Finally

This library now has to support both v0.x and v2.x of the Novu API.
@vertigo7x — the issue you’re seeing is likely due to payload differences between versions.

Please check which version of the API you’re calling (note: the cloud version is shown in the UI menu), and log the actual payloads sent across the wire — especially in the case of a 422 error. These errors should include details about which attributes failed validation. If they don’t, that’s something the API team needs to improve.

To debug further, it would also be helpful to include links to the relevant API docs or implementation, so we can cross-reference those against the C# client’s models (e.g., CreateData or EditData objects).

[toddb]

@atanas-todorov-assent @vertigo7x

Changes are pushed here

https://github.com/novuhq/novu-dotnet/tree/106-subscribers-cannot-be-notified-by-topic