Some v2 API endpoints don't work on self-hosted Novu
I just upgraded my self-hosted Novu instance to version 2.1.1 but the v2 workflows API doesn't work, it returns
/v2/subscribers endpoint works fine.
/v2/subscribers endpoint works fine.
N@Endy_, you just advanced to level 1!
P@Endy_
you will have to use legacy sdk and v1 apis with self hosted instance
you will have to use legacy sdk and v1 apis with self hosted instance
Egot it, thanks
T@Pawan Jain I am looking for documentation that explains this all clearly and precisely. I need to know for two reasons: I'm maintaining an SDK that has v2 api users logging bugs and I also have a self-hosted instance. I have found https://docs.novu.co/community/project-differences
For example, you say "legacy" SDK, I'm even unsure about that.
I can't find the discussion and am really happy to document it and provide it back. Please point me in the right direction
@Dima Grossman
Thanks in advance.
For example, you say "legacy" SDK, I'm even unsure about that.
I can't find the discussion and am really happy to document it and provide it back. Please point me in the right direction
@Dima Grossman Thanks in advance.
Understand the difference between Novu Project and Novu Cloud
T@Endy_ here is an diff between Project/Self-Hosted (0.24.7) and Cloud (2.1.1) when deployed locally (see https://github.com/OpenAPITools/openapi-diff)
https://github.com/novuhq/novu-dotnet/blob/106-subscribers-cannot-be-notified-by-topic/specs/2.1.1/diff.html
I had tried to keep track of changes in the novu-dotnet sdk
https://github.com/novuhq/novu-dotnet/blob/106-subscribers-cannot-be-notified-by-topic/specs/2.1.1/diff.html
- subscribers and workflows endpoints are upgraded (v2)—but because in a new namespace are new
- subscribers, workflows removed
- also organizations, environments, notification-groups, notification-tempmlates, notification-templates, tenants, feeds, workflow-overrrides—seem also to be removed which is strange because organizations for instance is central
- whole lot of changes
I had tried to keep track of changes in the novu-dotnet sdk
D@todd I'm pushing right now to add c# to be part of our auto SDK generation with Speakeasy, so this will be up-todate with the open api spec and won't require the manual updated of the #net sdk (similiar to how we auto generate the typescript one). Will that be helpful for you?
T@Dima Grossman thanks for the response.
Perhaps, but I also maintain a C# Sync that uses that library and the abstractions from openapi spec are really not idiomatic for C#. Speakeasy may solve that. Don't forget there is a user base already on the current SDK that will need to be migrated.
The problem lies that the openapi spec from what I can tell is wrong. Endpoints have been removed that are current. Take for instance organizations. The endpoint is there and used in the dashboard, but the code has attributes has it excluded from the openapi spec.
I have to say that the shift from no-code workflows to code-first is hard to follow and it has taken me days to piece this together. I still can't even tell if no-code is going to remain—given the architecture of the code-first requiring a bridge application I would have thought so. But the dashboard looks like it will ditch it.
Before you go speakeasy for C#, could we evaluate its results? I might be that there are two and I'll happily take a back seat. But I really think the openapi is wrong—so I need to work out what I have missed.
Thanks for your patience.
Perhaps, but I also maintain a C# Sync that uses that library and the abstractions from openapi spec are really not idiomatic for C#. Speakeasy may solve that. Don't forget there is a user base already on the current SDK that will need to be migrated.
The problem lies that the openapi spec from what I can tell is wrong. Endpoints have been removed that are current. Take for instance organizations. The endpoint is there and used in the dashboard, but the code has attributes has it excluded from the openapi spec.
I have to say that the shift from no-code workflows to code-first is hard to follow and it has taken me days to piece this together. I still can't even tell if no-code is going to remain—given the architecture of the code-first requiring a bridge application I would have thought so. But the dashboard looks like it will ditch it.
Before you go speakeasy for C#, could we evaluate its results? I might be that there are two and I'll happily take a back seat. But I really think the openapi is wrong—so I need to work out what I have missed.
Thanks for your patience.
Tps is Novu Project just the self-hosted version?
D- Speakeasy is handling the relevant language adjustments per-best practices, I think the path forward is that I can release an alpha version so we can try it out and adjust as-per needed.
- The whole v2 workflow engine + dashboard is running on top of the code-based architecture. Meaning that behind the scene the UI based workflows are working with a "hosted by us" bridge endpoint, and optionally users can create code based workflows, but it's not a mandatory step. Platform wise, the pipeline looks exactly the same for both scenarios.
- Novu Project === Self Hosted. @George is currently finalizing the OSS v2 dashboard images and is working on updating the terminology of this page to better explained.
T@Dima Grossman Thanks, for clarifications—I will happily look at an alpha version (in fact, bring it on it takes a lot of time and effort from me as no-one else is doing work on it).
THey @Dima Grossman
One still outstanding from my message, I’m running into something I think needs clarification regarding the OpenAPI spec.
It seems like the OpenAPI spec might be “incorrect” or incomplete — and I think digging into this could surface some important design context.
Looking at this line:
https://github.com/novuhq/novu/blob/fbb1dded0d4d880fa29b2057dd524b873d3ef64d/apps/api/src/app/organization/organization.controller.ts#L52
The
Could you explain the design thinking behind “hiding” this?
From my perspective, it seems like there’s more functionality available in the backend than what’s exposed/documented.
• Is this intentional?
• If so, is it something that could be reconsidered for future improvements?
Really appreciate any clarification here — trying to make sure I’m correctly understanding the boundary between what’s “official” and what’s “actually available.”
From a developers perspective, your product requires it all open so I can go headless which is one of the original propositions—and a great one!
Thanks a lot!
One still outstanding from my message, I’m running into something I think needs clarification regarding the OpenAPI spec.
It seems like the OpenAPI spec might be “incorrect” or incomplete — and I think digging into this could surface some important design context.
Looking at this line:
https://github.com/novuhq/novu/blob/fbb1dded0d4d880fa29b2057dd524b873d3ef64d/apps/api/src/app/organization/organization.controller.ts#L52
The
@ApiExcludeController() attribute is excluding the whole OrganizationController from the OpenAPI spec (unless I’m misunderstanding?).Could you explain the design thinking behind “hiding” this?
From my perspective, it seems like there’s more functionality available in the backend than what’s exposed/documented.
• Is this intentional?
• If so, is it something that could be reconsidered for future improvements?
Really appreciate any clarification here
— trying to make sure I’m correctly understanding the boundary between what’s “official” and what’s “actually available.” From a developers perspective, your product requires it all open so I can go headless which is one of the original propositions—and a great one!
Thanks a lot!
D@todd the whole organization controller functionality is an internal API which is actually not even used on the cloud version of Novu, as we are using Clerk behind the scene for users and organization management. Hence we are not exposing this as part of our offering and keeping it as an internal API. Do you have some specific usecase for the org apis?
T@Dima Grossman I wanted to explain my use case clearly:
I need to provision two organizations.
Then, I need to provision workflows under each organization.
How is this expected to be done with the current setup?
And how will this be migrated in the future, especially with code-first workflows?
At this stage, the answer is yes, I need full organization separation.
(For context: my application is B2B2C — the admin users belong to one organization, and the customer users belong to the other.)
Thanks for your help!
I need to provision two organizations.
Then, I need to provision workflows under each organization.
How is this expected to be done with the current setup?
And how will this be migrated in the future, especially with code-first workflows?
At this stage, the answer is yes, I need full organization separation.
(For context: my application is B2B2C — the admin users belong to one organization, and the customer users belong to the other.)
Thanks for your help!
DHave you tried calling the org API endpoint even tho they are not exposed via the open api ? from the look of it they are still marked as external api accessinle meaning could be accessed using an API key
TThanks @Dima Grossman — yes, those endpoints do work when called directly.
The challenge is that they aren’t included in the OpenAPI spec. This leads to issues where any differencing or validation tools interpret them as “removed” or non-existent, since they’re undocumented. For cases like auto-generated clients or maintaining a typed SDK, this makes things particularly difficult — especially in a code-first setup where strong typing and alignment with the spec are critical.
Documenting these endpoints, even minimally, in the OpenAPI spec would go a long way toward improving developer experience and long-term maintainability.
Appreciate your help!
The challenge is that they aren’t included in the OpenAPI spec. This leads to issues where any differencing or validation tools interpret them as “removed” or non-existent, since they’re undocumented. For cases like auto-generated clients or maintaining a typed SDK, this makes things particularly difficult — especially in a code-first setup where strong typing and alignment with the spec are critical.
Documenting these endpoints, even minimally, in the OpenAPI spec would go a long way toward improving developer experience and long-term maintainability.
Appreciate your help!
D@todd for the dotnet SDK, you should be able to find version 1.0.6 available at: https://github.com/novuhq/novu-csharp
Please let me know if this one works for you
Please let me know if this one works for you
GitHub
Contribute to novuhq/novu-csharp development by creating an account on GitHub.
T@Dima Grossman I have had a look. It will work.
Immediate limitations: no DI for HttpClient or use of the IHttpClientFactory and only have a singleton client; lots of untyped structures because it uses a Dictionary<string, object>.
I would need to work with it to see how nice it is to use in practice. But bottom line if the library had been like this when I arrived a couple of years ago I would not have had to do the work I have! So bring it on but I think SpeakEasy could easily up their game around some of the core library usage and DI extensions methods. Production systems in dotnet have a DI pipeline that this service should have a catchall extension method for.
One problem you are going to have is that there are no tests across this code and the reality of serialisation can be a pain that you are deferring to production cases.
Can I suggest that given it is auto-generated, think about a versioning strategy that matches the api image—I see that you have put the fix in place to version to the openapi spec. Currently, 1.0.0 has been used.
What package name are you planning release under. I also see that you have used Novu as your namespace. The downstream affects of that will cause conflicts.
Immediate limitations: no DI for HttpClient or use of the IHttpClientFactory and only have a singleton client; lots of untyped structures because it uses a Dictionary<string, object>.
I would need to work with it to see how nice it is to use in practice. But bottom line if the library had been like this when I arrived a couple of years ago I would not have had to do the work I have! So bring it on but I think SpeakEasy could easily up their game around some of the core library usage and DI extensions methods. Production systems in dotnet have a DI pipeline that this service should have a catchall extension method for.
One problem you are going to have is that there are no tests across this code and the reality of serialisation can be a pain that you are deferring to production cases.
Can I suggest that given it is auto-generated, think about a versioning strategy that matches the api image—I see that you have put the fix in place to version to the openapi spec. Currently, 1.0.0 has been used.
What package name are you planning release under. I also see that you have used Novu as your namespace. The downstream affects of that will cause conflicts.
T@Dima Grossman A separate point, the v1 API versions that are still in the product but not in the openapi have not been addressed and I don't see how you are helping people with upgrade paths. I have opinions about that approach that I would happily to share privately.
MTodd, Its released on nuget under same namespace but starting version 1. https://www.nuget.org/packages/Novu/1.0.6
DThank you for the feedback @todd ! passing this feedback to the speakeasy team, and will keep you posted. Feel free to send a DM on any other subject. Happy to chat
T@Himanshu you have just taken over a package name without a migration strategy. This is not fair or careful on people's time or expertise. I tried above to warn against doing this—politely.
T@Himanshu where is all the community documentation for people who have production systems that they are trying to maintain? What's the upgrade path? There isn't one.
D@todd my apologies for this, there seem to be some mistake when publishing the new SDKs, we should have published it under a new namespace instead of overriding the default Novu one.
I will work with @Himanshu to add a relevant section when it comes to the migration path to 1.0.6, since it's a major version up, this should not affect existing systems unless they will upgrade to the newer major version. This guide will be added as a link to both the old github repo and the new one.
I will work with @Himanshu to add a relevant section when it comes to the migration path to 1.0.6, since it's a major version up, this should not affect existing systems unless they will upgrade to the newer major version. This guide will be added as a link to both the old github repo and the new one.
