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.
13 Replies
@Endy_, you just advanced to level 1!
@Endy_
you will have to use legacy sdk and v1 apis with self hosted instance
got it, thanks🙏
@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.
Novu Project and Novu Cloud | Novu Documentation
Understand the difference between Novu Project and Novu Cloud
@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
- 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 am still trying to make sense of all this and can't find anywhere that does that.
I had tried to keep track of changes in the novu-dotnet sdk
@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?
@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.
ps is Novu Project just the self-hosted version?
- 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.
Hope this clarifies things for you 🙏
@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).
Hey @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
@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!@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?
@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!
Have 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
Thanks @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!