If Mailgun is your current email service provider and you’re looking to make a change, this how-to will help you migrate to SendGrid by highlighting the differences between the two services.
If you’d like to take a look around before getting going, check out SendGrid’s documentation that includes great resources before you dive into the API reference and details.
If you’re looking for the SendGrid equivalent of certain Mailgun functionality, the following table will help:
|SendGrid Term||Mailgun Term|
|Multiple Credentials||Multi User Access|
|subuser||Mailgun does not provide discrete subusers.|
|X-SMTPAPI||Mailgun uses a discrete X-Header for each configuration option, such as X-Mailgun-Recipient-Variables|
|Inbound Parse Webhook||Routes|
|Marketing Campaigns||No Equivalent|
Getting an API Key
First, you’ll need a SendGrid account. Next, you should create an API key that you’ll use for sending. Go to Settings -> API keys, or use this link. A SendGrid and security best practice is to use a different API key for each of your different apps. API keys have granular permissions, so you can enable or disable read or write access for individual endpoints. Make sure the API key you create has full access to Mail Send. (Note: Your account must pass provisioning before you can create an API key.)
We have a number of officially supported API Libraries to make integration easier for our customers. If you’re rewriting any code, or refactoring how you communicate with your ESP as part of your migration, now is a good time to evaluate these libraries:
- sendgrid-csharp – Official C# library
- sendgrid-go – Official Go library
- sendgrid-java – Official Java library
- sendgrid-nodejs – Official NodeJS library
- sendgrid-php – Official PHP library
- sendgrid-python – Official Python library
- sendgrid-ruby – Official Ruby library
If you’re sending via SMTP, there are a few differences you should be aware of. To authenticate, provide the string ‘apikey’ as the SMTP username, and use your API key as the password. Then point your hostname to smtp.sendgrid.net.
You can connect using SMTP via unencrypted or TLS on ports 25, 2525, and 587. You can also connect via SSL on port 465. In general, we recommend port 587 as it tends to result in the fewest issues with hosting providers.
The mechanism for customizing email sent via SMTP is our X-SMTPAPI header. This header will allow you to define substitutions, send batched mail-merge style requests, and control filters (like click tracking) that are active for your send.
The main endpoint for sending email is the Mail endpoint. Requests to this endpoint are authenticated via an authorization header with your API key presented as a bearer token. You can find a more detailed example in our docs.
Personalizations allow you to define recipients and metadata for each message, such as substitution values for customizing content or custom_args for associating messages with user IDs or order numbers. There are a number of examples of personalizations for common use cases. You can also find cURL example calls.
Features like click tracking are configured via the tracking_settings and mail_settings parameters. You can also schedule sends up to 72 hours in advance by using the “send_at” parameter.
Attachments sent via HTTP are handled differently than Mailgun. Mailgun requires a multipart/form-data POST containing the files to be attached. With SendGrid, content is encoded as Base64 and embedded directly in the JSON payload alongside MIME information, keeping your entire message in the same payload and simplifying your HTTP request. You can read more about including attachments in the following section of our Documentation Classroom.
SendGrid provides two webhooks: the Event Webhook for posting real-time events, and the Inbound Parse Webhook for receiving emails and programmatically responding to them. The data shapes and payloads are a bit different from what Mailgun provides. We also do not currently support routing inbound messages to different callback URLs; you’ll need to handle that sort of logic in code rather than at the API level.
Non-email API Endpoints
For API endpoints that don’t send email, check out the API v3 overview. We use intuitive HTTP methods and response codes in most cases, and enforce rate limits for calls. API v2 is deprecated, though there is no timeline to stop supporting it. All new integrations should prefer v3. API v3 authentication is accomplished by an authentication header with a Bearer token.
We have a full-featured platform for managing contact lists, creating and designing templates, A/B testing different templates, and scheduling campaigns. This is all wrapped in a UI that is easy to use for non-developers. And of course you can also access all of these features via our Marketing Campaigns API.
A Few FAQs
Q: Do you support templates for transactional emails?
A: Yes—and they’re dynamic! SendGrid’s transactional templates feature native support for Handlebars syntax. In addition to basic replacement and substitutions, you can use enumerations/iterate over lists, take advantage of conditionals and more. To learn more, click here.
Q: Is there a sandbox or a way to test my emails without sending them?
Q: Is it possible to transfer my IP address/sender reputation to SendGrid?
A: We can’t migrate an IP or reputation but we can help warm up a new IP for you automatically.
Q: Does SendGrid support enforced TLS?
A: Absolutely. You can require that receiving servers support TLS and drop messages going to servers that don’t comply.
Q: Can I allow my recipients to define the types of emails they want to receive?
A: Yes. Giving your recipients more control of their email lets you send email people want, which is better for everyone. Check out unsubscribe groups for more information.
If you’re interested in migrating to SendGrid, you can find more information at sendgrid.com/pricing.