Dropping support for SendGrid

[medmunds]

django-anymail is dropping support for SendGrid

In June 2025, Twilio SendGrid disabled use of Anymail's testing account. This means we can't run regular integration tests, verify features or triage bug reports relating to SendGrid. As a result, django-anymail must drop official support for SendGrid.

If you are using django-anymail in your Django app to send or receive email via SendGrid:

• It will probably keep working, at least for a while. There are no plans to remove the existing SendGrid integration from Anymail, and there's not an urgent need to change your code.
• But you should be aware that Anymail's SendGrid integration is no longer tested. In the next Anymail release, you'll start getting warnings to alert you of this change in status. (See the docs to suppress these warnings.)
• Any future problems will likely be discovered in production, by users like you, and we won't be able to verify proposed fixes. (Historically, there have been bugs or new features affecting the SendGrid integration roughly once every year or two.)

If you're from SendGrid developer relations and want to help, see Q1 below.

If you're a paying SendGrid customer impacted by this change, see Q2 below.

More info

django-anymail is a free, open-source library that helps developers integrate transactional email services in projects built with the popular Django web framework. Anymail has supported SendGrid since 2016. It is maintained entirely by volunteers. Anymail is not a business and does not have financial backing from any ESP.

To ensure Anymail integrates correctly with ESP APIs, we maintain a testing account with each supported ESP. We use it for:

• live integration tests, which run for each code change plus once weekly to catch API or dependency changes
• one-off tests to triage and reproduce bug reports about django-anymail's integration with that ESP

These test accounts email only "sink addresses" or Anymail contributors working on a specific issue. They are never used for commercial or any other "real" email, and the typical send+receive volume is well under 250 messages/month. (Here are Anymail's SendGrid integration tests.)

Most ESPs offer some sort of free tier that more than covers Anymail's test usage. Until recently, SendGrid was one of them. Sometime earlier this year, SendGrid changed its free tier to a free trial with a 60-day time limit. The sendgrid.anymail.dev account we've used for the past nine years apparently hit that limit last month, and integration tests started failing.

Anymail's policy is we only support ESPs we can test.

Experience has shown live testing access is critical to correctly integrating with an ESP. No matter how good an ESP's documentation, there are always things that are incomplete, outdated, or just plain wrong. (SendGrid has been no exception.)

I reached out to SendGrid last month¹ about retaining a test account for django-anymail. Their support team said they would forward my request to SendGrid developer relations. But I haven't heard anything since then. Since we're no longer able to test Anymail's SendGrid integration, I'm changing it to "unsupported" status.

I want to be clear I think it's perfectly reasonable for SendGrid to have time-limited free trials. They're running a business, and I imagine the former free tier was an expense without much return (and probably a lot of spammers). This isn't a generic complaint about SendGrid eliminating its free plan.

But I also need to be clear that Anymail is not running a business. Our open-source contributors volunteer their time and expertise without payment. So it's equally reasonable for the django-anymail project to decline to pay retail rates for the privilege of supporting SendGrid's own customers.

Questions

Q1: What would it take to return SendGrid to officially supported status?

We need access to a free or minimal-cost² account that can support sending and receiving email and webhook notifications for the small testing volumes described above.

If you're from SendGrid and can help, reach out to me here, via email (address in my GitHub profile), or at any of the contact addresses mentioned in SendGrid support ticket 21854478.

Q2: Is there anything django-anymail users can do?

If you are a paying SendGrid customer, please contact your account rep or SendGrid support, explain that you have been relying on django-anymail, and ask that they escalate this issue to developer relations.

If you'll incur an unexpected engineering expense to switch from django-anymail to another integration approach, it might help to mention that.

(Please be polite. Realize that SendGrid support has been inundated with complaints from people who were using the free plan for low volume commercial sending. It may take several tries to communicate how this is different and get past the canned responses.)

Q3: Why can't django-anymail just pay for an account? Doesn't SendGrid benefit Anymail's business?

Again, Anymail is not a "business." It's an open-source project maintained entirely by volunteers. There's no company behind Anymail. Nobody makes any money from it.

In fact, who does benefit from django-anymail's support for SendGrid is:

• SendGrid's (paying) customers who use django-anymail in their Django apps
• Twilio SendGrid itself, which gets free engineering to support SendGrid in Django (including an easy migration path to SendGrid from other ESPs)

Q4: Could someone else donate an API key or cover the cost of a testing account?

No, for several reasons. (But I appreciate the offer.)

The main one is I'm not comfortable setting that precedent. Anymail's contributors (including me) have donated our time and expertise to ensure django-anymail supports SendGrid well. We've also provided hundreds of hours of free consulting to SendGrid itself, helping them diagnose obscure technical issues in their product (including responsibly reporting a high-severity security issue discovered through Anymail testing). I don't think it's appropriate to ask Anymail's volunteers to pay SendGrid for that privilege. And I don't think paying SendGrid would be fair to other ESPs who have provided free testing accounts for Anymail.

(Also, there would be tax complications I'd rather not deal with. And an API key wouldn't be sufficient; for testing webhooks and account-level settings we actually need direct access to a full SendGrid account.)

Q5: What are other options for django-anymail users?

If you're not comfortable using django-anymail's SendGrid integration now that it's untested, you can:

• Switch to a fully supported ESP. django-anymail was designed to make switching ESPs relatively easy. (Anymail's original purpose was to help users migrate from MailChimp to SendGrid or Mailgun.)

• Switch to Django's built-in SMTP EmailBackend for sending. SendGrid has instructions for that integration.

  • If you're using Anymail's extended sending features, you'll need to convert them to the equivalent SendGrid proprietary headers.
  • For tracking and receiving webhooks, you'll need to write (and test and maintain) your own Django views.

• Switch to the third-party django-sendgrid-v5 package (which appears to still run integration tests).

  • It uses different EmailMessage extension properties than django-anymail, so you'll need to convert any extended sending features.
  • For tracking and receiving webhooks, you'll need to write your own Django views. (django-sendgrid-v5 includes some webhook helpers and shows examples in its documentation. You might want to review the package's dependencies for open security issues first.)

Footnotes

1. If anyone from SendGrid sees this, it's your support ticket 21854478. ↩

2. I'm able to provide a credit card to help prove I'm not a spammer, and I'm willing to pay actual usage-based fees that are expected to total less than $1 (one USD) per year for the testing send/receive volumes described above. (E.g., I pay about 36 cents each year for Anymail's Amazon SES testing.) ↩