Sustainable Use License clarification regarding use as an integration backend

Questions
1

Hi all,

We emailed license@n8n.io about this 10 days ago but haven’t received a response, so I’m asking here in case someone can help.

We are a Japanese company providing chatbot and voice assistant solutions as a multi-tenant SaaS. We are evaluating a self-hosted n8n instance as the internal backend for optional third-party integrations.

To give more detail, the n8n instance would be used only as internal integration infrastructure. Our tenants and their end users would interact only with our chatbot or voice assistant. They would not receive n8n accounts or have access to the n8n UI, API, workflows, or credential interface. A small group of our employees would design and maintain the workflows, which our AI assistants would invoke through webhooks and tool calls.

The integration capability would be included within our standard SaaS subscription. It would not be sold as access to n8n or as a separate workflow automation product. Our core chatbot and voice assistant services would continue to function without n8n.

For an actual use case example, an end user may ask a tenant’s voice assistant about an order. Our AI may invoke an internally maintained n8n workflow as a tool and pass information such as the tenant and order identifiers. The workflow could retrieve information from the tenant’s HubSpot account, or perform an action such as updating a record, then return the result to our application.

Tenants would authorize their third-party integrations through an OAuth or credential setup flow within our SaaS. We have not yet decided where those credentials should be stored. One option would be to store and use the relevant third-party credentials securely within n8n, but we believe this is not allowed. An alternative approach would be to keep the third-party credentials in a vault or proxy service operated by us. In that second model, n8n would call our internal service with the necessary business context, while our service would handle authorization and communication with the third-party API, keeping the third-party API credentials outside n8n.

Going through the forum, Jan’s answers in N8n as a SaaS backend — How much does the license allow? covered most of our case, but one variation isn’t addressed there, so I wanted to confirm it.

Could you please confirm whether the use case described above would be permitted under the Sustainable Use License? If there are architectural boundaries or implementation practices you recommend for this use case, we would appreciate your guidance.

Thank you for your time, and for all the work you put into an amazing project!

2

Hey @u-karakulak, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@jan, @achamm, @Piotr_Sikora - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Hi @u-karakulak

This is my take on your use case. It is not legally binding. You will still need to check with license@n8n.io.

Your company, a Japanese multi-tenant SaaS provider, is evaluating a self-hosted n8n instance to serve as an internal backend for optional third-party integrations (e.g., HubSpot) triggered by your AI chatbots and voice assistants. In this model, end-users and tenants would never interact with the n8n UI, and only a small group of your employees would design and maintain the workflows, which the AI would invoke via webhooks.

However, this specific use case is not permitted under the standard n8n Sustainable Use License (SUL). The deciding factor for SUL compliance is not whether the end-user sees the n8n interface, but rather whose credentials and data are being processed. Because the workflows would execute actions using your tenants’ third-party credentials to access their specific accounts, it falls outside the “internal business purposes” allowance of the free license.

Furthermore, the proposed architectural workaround of using an external vault or proxy service does not resolve the licensing restriction. Even if third-party credentials are kept outside of n8n and passed dynamically at runtime (e.g., via webhook payloads), the n8n execution engine is still actively processing and acting upon customer-specific credentials on behalf of the tenant, which violates the SUL terms.

To proceed legally and architecturally soundly, you have three viable paths:

(1) Purchase a commercial n8n Embed License, which is explicitly designed for multi-tenant SaaS embedding and customer credential management
(2) Redesign the integration so n8n only ever authenticates using your company’s own master credentials or service accounts, never tenant-specific ones or
(3) Shift to a decentralized deployment model where isolated n8n instances are hosted on each tenant’s own infrastructure, keeping your role strictly as a maintenance consultant.

image
image1102×153 3.81 KB

4

Hi @u-karakulak
The deciding line is whether n8n itself uses a tenant’s own credentials to reach that tenant’s account, not whether anyone sees the n8n UI. Your first option, holding tenant HubSpot credentials in n8n, is the exact case the docs mark as not allowed. Your second option is a different thing: if your vault service holds the credentials and makes the HubSpot call, and n8n only passes business context to that service and gets a result back, n8n never acts on tenant credentials and stays inside the license.
See this:

What pushes it into Embed is passing the tenant token into n8n at runtime and letting an n8n node make the authenticated call, regardless of where that token was stored. So keep every third-party API call inside your proxy and keep n8n on plain internal HTTP calls to it.
The docs also state that backend use, workflows running behind the scenes with end users never seeing n8n, is covered on all paid plans under the standard license with no separate agreement, and that OEM is only needed when your users work in the n8n editor directly.

Background on where the SUL ends and Embed begins:

5

@kjooleng @Anshul_Namdev
Thanks both, for a very fast and well explained messages!

Sorry, my wording wasn’t clear. The first option, with the credentials stored inside n8n, is the one we already assume isn’t allowed.

The second one is what we had interpreted as allowed and are planning around: the credentials stay in a proxy service we run, n8n only ever calls that proxy, and the proxy makes the authenticated third party call. n8n would never store, receive or pass a tenant credential.

I’m not fully confident about that reading though, since I understood your two answers a little differently on it. Jan’s reply in the thread above says it’s fine if our SaaS does the connecting elsewhere, which sounds like our case, but I can also see how a proxy sitting between n8n and the third party might look like working around the rule rather than genuinely falling outside it. I’d rather confirm that before violating any terms.

I appreciate your answers a lot and will follow up with the license@n8n.io for final confirmation.

But, additionally If we do need a commercial agreement for this, is it Embed specifically, or could a standard paid plan such as Business cover it?

6

Sounds like you need a license as most of the value for your clients is from n8n it self. As the logic is actually built in n8n, this is where the value is.
(could be understanding it wrong, just going of your last message in the thread)

Assuming your clients never see n8n and only interact with your own platform a business/enterprise license would be what you need.
Embedded license is only needed if you “whitelabel” n8n.

edit:
Just checked Jan’s answer. His point 6 confirms you need enterprise not embed.
They used to have Embed as the requirement for this, but in practice were allowing you to have enterprise for it for a long time as Embed is a bit of a weird license.

7

The clause doing the work in the SUL is “internal business purposes,” and the practical test isn’t whether tenants can see the UI — it’s whether your customers are receiving the value n8n produces. A credential proxy solves the tenant-credential-storage problem, which is a real and separate problem, but it doesn’t change that answer, so I wouldn’t expect it to move you back inside the free tier.

When you write license@n8n.io, send the actual architecture diagram rather than a prose description. You’ll get a far less hedged reply, and you want that answer in writing before it’s load-bearing for your pricing.