Not able to integrate with sendgrid

AI-generated summary

User Satwik_Kansal is having trouble integrating Discourse with Sendgrid, receiving an “Authentication failed: Bad username / password” error. Richie suggests checking the Sendgrid username, which is not the API key but rather a value found in the Teammates section of the Sendgrid dashboard.

However, forkequity notes that their Sendgrid API username is “apikey” (lowercase) and it’s working for them. misterjtc points out that the Discourse docs are confusing, as “apikey” should be left alone and not replaced with the actual API key.

Satkik_Kansal ultimately decides to switch to Mailgun due to the issue. ivan12 is having the same problem and is unsure whether to use “apikey” or add a teammate to resolve it.

Hi,

I’m trying to use Sendgrid email service and keep getting this error in the logs

Job exception: 535 Authentication failed: Bad username / password

I’m not sure what I’m doing wrong, here’s how my configuration looks like

 DISCOURSE_SMTP_ADDRESS: smtp.sendgrid.net
 DISCOURSE_SMTP_PORT: 587
 DISCOURSE_SMTP_USER_NAME: apiKey
 DISCOURSE_SMTP_PASSWORD: 'SG.xxxx.xxxxxx.xxxx'

I’ve also tried to use port 2525 on the suggestion of Fresh install. Works. Sendgrid not sending emails - #5 by Ham , but that didn’t work either.

I’m able to establish a connection using telnet.

Can someone please help? Any idea what I could be doing wrong?

From the same server that your Discourse is on?

Apologies if this is a silly question but is your SendGrid username actually: apiKey

:thinking:

I only ask, as it’s an unusual choice of account name…

Yes

No, I don’t think there’s a concept of username in sendgrid, I just followed the documentation here discourse/docs/INSTALL-email.md at main · discourse/discourse · GitHub

I might be wrong also, but I don’t see any username info in my sendgrid account.

They use different terminology but you’re still connecting to what is essentially a standard SMTP server, which will require authentication.

Go to the Teammates section - https://app.sendgrid.com/settings/teammates

In there you will see the account details that are able to send email:

The value in the “Username” column is what you need to enter in the Discourse setting DISCOURSE_SMTP_USER_NAME

So if the “Username” was SK2019 then you’d have something like:

DISCOURSE_SMTP_ADDRESS: smtp.sendgrid.net
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: SK2019
DISCOURSE_SMTP_PASSWORD: 'xxxx.xxxxxx.xxxx'

I tried that but didn’t work. The Sendgrid docs mention to use apiKey as username, but that doesn’t seem to be working.

Maybe I should reach out to the sendgrid team and seek their help.

Did you use apiKey when using telnet?

Yes, I followed instructions at How to send an Email with SMTP | SendGrid Docs | Twilio and they worked! Not sure what am I missing in discourse configuration.

Do the four lines in your config file look like mine (above)?

With the correct DISCOURSE_SMTP_USER_NAME that matches the one displayed in your Teammates page on SendGrid?

Yes, the username is the one displayed in the the Teammates page, the password is the key I generated (telnet works using this key), and other two fields are exactly the same.

May I know what version of discourse are you using, I’m using beta, I suspect that could be the issue.

Anyways, I’m planning to switching to mailgun, I tried it today, and it works seamlessly (though it’s expensive, but have no other options atm)

FWIW @Satwik_Kansal our Sendgrid API username is “apikey” – not “apiKey”. working great.

Having the same problem. What is the tldr here? Use “apikey” (not working) or add a team mate (it’s empty)?

For the record, the docs make this pretty confusing and this is not the first time I have found myself googling this exact issue trying to find the solution.

Docs currently have:

SendGrid — 40k emails on a 30 day trial

SMTP server address? smtp.sendgrid.net
SMTP user name?      apikey
SMTP password?       [SendGrid API Key]

EDIT: What I think is confusing people is that they (like me) think apikey means put your apikey here but infact it should be left alone!

Crazy, right?

I would imagine this has thrown 99% of people trying it :confused:

(myself included at the time)