`sendInBlueApi` predefined credential type broken in HTTP Request node after upgrade to v2.20.7 — causes misleading DMARC 400 error from Brevo API

Questions
1

Reporting a similar issue to what happened a year ago in HTTP Request Module Not Passing Authentication

Describe the problem/error/question

After upgrading to v2.20.7-exp.0, the HTTP Request node using predefinedCredentialType: sendInBlueApi silently fails to inject the api-key header correctly into requests. This workflow had been running successfully for months with zero changes on our side — no DNS changes, no payload changes, no Brevo configuration changes.

The broken authentication causes Brevo’s API to return a misleading 400 DMARC policy error instead of a 401 Unauthorized, which makes it appear to be a sender/domain configuration problem and is extremely hard to diagnose.

Switching to Generic Credential Type → Header Authentication resolved the issue immediately with the same API key and the same payload — confirming the bug is in how n8n injects the sendInBlueApi credential into HTTP Request nodes.

What is the error message (if any)?

NodeApiError: Bad request - please check your parameters
400 - "{"code":"invalid_parameter","message":"Unable to create/update campaign. Due to DMARC policy, you cannot use this sender. Please choose another sender."}"

Please share your workflow

{
  "nodes": [
    {
      "parameters": {
        "method": "POST",
        "url": "https://api.brevo.com/v3/emailCampaigns",
        "authentication": "predefinedCredentialType",
        "nodeCredentialType": "sendInBlueApi",
        "sendBody": true,
        "specifyBody": "json",
        "jsonBody": "={\n  \"name\": \"Test Campaign\",\n  \"templateId\": 1,\n  \"sender\": {\n    \"name\": \"Test Sender\",\n    \"email\": \"sender@yourdomain.com\"\n  },\n  \"subject\": \"Test subject\",\n  \"recipients\": {\n    \"listIds\": \n  },\n  \"scheduledAt\": \"{{ $now.plus({ minutes: 1 }).toISO() }}\"\n}",[1]
        "options": {}
      },
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.4,
      "position":,[2]
      "id": "79a604ee-c9da-405a-beb0-02f917556ae4",
      "name": "Create Brevo Campaign",
      "credentials": {
        "sendInBlueApi": {
          "id": "YOUR_CREDENTIAL_ID",
          "name": "Brevo account"
        }
      }
    }
  ],
  "connections": {},
  "pinData": {},
  "meta": {
    "templateCredsSetupCompleted": true
  }
}

Share the output returned by the last node

{
  "code": "invalid_parameter",
  "message": "Unable to create/update campaign. Due to DMARC policy, you cannot use this sender. Please choose another sender."
}

Evidence this is an n8n issue, not a Brevo/DNS configuration issue:

  • Domain fully authenticated in Brevo (DKIM :white_check_mark:, DMARC :white_check_mark:, Sender verified :white_check_mark:)
  • Single DMARC DNS record, correct: v=DMARC1; p=none; rua=mailto:rua@dmarc.brevo.com
  • The exact same payload sent via curl with the API key works perfectly
  • Creating the campaign manually from the Brevo web UI also works
  • Switching the HTTP Request node to Generic Credential Type → Header Authentication (Name: api-key, same API key) fixed the issue immediately with zero other changes

Workaround:

  1. Create a new credential: type Header Authentication, Name: api-key, Value: your Brevo API key
  2. In the HTTP Request node set Authentication → Generic Credential Type → Header Authentication
  3. Everything else (URL, JSON body) stays unchanged

Information on your n8n setup

  • n8n version: 2.20.7-exp.0
  • Database: SQLite
  • EXECUTIONS_PROCESS setting: main
  • Running n8n via: Docker (self-hosted)
  • Operating system: Linux
3

Try downgrading to 2.20.6 . Does that help?
If not, can you revert to the previous working working?

Possibly a regression issue

4

Unfortunately I can’t risk doing downgrades on this production instance.

I suspect this regresion was introduced after the upgrade I did on May 13th.

5

Most likely you have to file an regression issue on Github

6

@nukeador: I’m not sure if this can help. But I had the same problem with Make.com yesterday. Thanks to your workaround, I was able to solve the problem. Conclusion: I think the problem might be coming from Brevo! :wink:

7

No it’s not coming from Brevo because a plain normal manual api call works, as well as if you use a header auth on n8n.

8

I tested it on my end. I encountered the issue again just now. By retrying the API call multiple times, it eventually goes through. For me, it’s definitely coming from Brevo.

9

The error is coming from and doesn’t look to be an n8n issue. If it was an auth issue you would see an error to say that but the 400 DMARC and the message about the sender looks very specific to Brevo and the account.

I would reach out to their support and they should be able to provide more assistance with this.

10

I did reach them and, as I commeted, doing a manual curl worked and using header auth instead of predefined auth worked on n8n (and keeps working).

So there is something wrong with https pedefined auth for brevo, something that changed on May releases.

I also read they can return error 400 and the wrong DMARC message sometimes when the api request is malformed.

11

@nukeador so was your case resolved?
If so, we kindly ask you to mark the best answer as a solution to help community members in resolving their doubts.

12

It’s not solved.

Using Brevo predefined auth option on HTTP Request node doesn’t work on the current n8n version.

14

@nukeador, I saw that you were using the experimental version. We have the stable update 2.21.4 available. Is it possible to update the version and get back to us?