Mailjet Credentials | Sandbox setting gets synced when working with environments

Hello there. My name is Timo from Stuttgart and I am new on this forum.

Describe the problem/error/question

We have setup 3 n8n deployments - lab, test and prod. We setup a github repo with 3 branches and linked the 3 deployments via the environments feature to those branches. All working fine so far.
Normally, for credentials only the empty container with the id gets synced but not the values. But for the mailjet credentials, the “sandbox” setting is gettings synced.
That is bad for us, as on lab and test we want the sandbox mode enabled but on prod we want it disabled. But that always gets overwritten on push and pull to prod. Is that by design so or a feature?
Thanks in advance for the help!
Timo

What is the error message (if any)?

Please share your workflow

Sorry, no workflow to share

Share the output returned by the last node

Information on your n8n setup

  • n8n version: 2.9.3 on all deployments
  • Database (default: SQLite): postgres
  • n8n EXECUTIONS_PROCESS setting (default: own, main): queue
  • Running n8n via (Docker, npm, n8n cloud, desktop app): docker in azure container apps environment
  • Operating system: runs on azure
1 Like

Hi @TimoNotonica you can either use external secrets and connect each n8n instance (lab, test, prod) to a different vault environment and store the sandbox, also you can do something like manually redisable the sandbox setting on prod after every pull you make as as far as i know that on on pulling existing credential values are not updated unless the credential name changes , so let me know what works for you.

Hi @Anshul_Namdev , thanks for your quick reply.

  • As we are on the business license we cannot use external credential store
  • the pull always overwrites the setting, even though it already existed
  • the manual re-disable is not an option as this might cause serious issues if you forget that

My only solution for now would be to have a sandbox-credential and a production-credential. In my flows I would need to add an “if” to check whether I am on lab, test and prod and use separate mailjet nodes with different credential-settings. This does not sound like an optimal way for me.

That’s why I was asking if that is a bug or by design.

1 Like

@TimoNotonica Understood, current workaround i would suggest is that the dual credential approach you described, and i recommend raising this as a bug as this should not be happening.

@TimoNotonica this looks like a bug, not a design decision. Here is what is happening under the hood.

n8n environments sync credential metadata along with values. For most credentials, the sensitive fields (API keys, passwords) are excluded from the sync — only the credential container and its non-sensitive properties are pushed. The Mailjet sandbox toggle is stored as a non-sensitive property (sandboxMode: true/false) rather than as a protected value, so the sync system treats it like configuration rather than a secret and moves it across environments.

This is the same category of issue as checkbox settings getting overwritten in other credential types. It is worth filing a bug at GitHub - n8n-io/n8n: Fair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400+ integrations. · GitHub with the label bug — the Mailjet credential definition should probably mark sandbox mode as environment-specific or omit it from synced properties entirely.

For now, the most reliable workaround I can think of that does not require dual credentials: use an HTTP Request node instead of the Mailjet node on your test/lab environments, pointing at the Mailjet sandbox API endpoint directly. This way the sandbox vs live distinction lives in the URL (which you can set via an environment variable N8N_VAR_MAILJET_BASE_URL) rather than inside the credential itself. A bit more setup but it means one credential, zero sync headaches.

The dual-credential approach you described works too — it is just more maintenance overhead. Either way, I would still file the bug so this gets fixed properly.

1 Like

@OMGItsDerek thanks for your reply.

That was very helpful to me, esp. in understanding the concept and your suggested approach.

I marked that as a solution.

Thanks!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.