SendGrid email integration for web and mobile back ends

SendGrid suits products that send both system email and marketing email from one account:

• You want a hosted service for API-based transactional email as well as marketing sends.
• Email content must be editable outside the codebase. Dynamic templates use Handlebars, and your code supplies the data for each message.
• You need delivery and engagement events pushed to your back end through the Event Webhook.
• You need to receive replies or attachments as HTTP requests. Inbound Parse does that.

Check these before you commit:

• Limits and features depend on your plan, so check the plans page. Dedicated IP addresses are documented for the higher plans, and the lower ones use shared pools.
• You need sending from the European region. That requires an EU subuser and is documented for Pro plans and above.
• You want to own your sending reputation fully, or stay inside one cloud vendor. A self-run mail server or a cloud-native sender may suit you better; SendGrid's documentation does not compare them.
• Your sender identity cannot be verified. Sending is restricted by sender verification and compliance checks.

SendGrid's documentation describes sending through the Mail Send API, an HTTP call that returns a success code when a message is accepted, or through SMTP using the user name "apikey" and an API key as the password. Dynamic transactional templates use Handlebars, with substitution, conditions and loops. The Event Webhook reports processing events such as delivered, deferred, dropped, bounce and blocked, and engagement events such as open, click, spam report and unsubscribe. Inbound Parse receives email at a dedicated subdomain and posts the parsed message and attachments to your URL. Suppression lists record bounces, blocks, invalid addresses, spam reports and unsubscribes. API keys carry permission levels, from full access down to custom access.

• Domain authentication: enter the root domain, because subdomains do not inherit it. DNS changes can take time to spread, and some DNS hosts append the domain to CNAME values and duplicate it. We check the records before launch.
• Suppressions: an address that bounced is blocked on later sends, and sends to suppressed addresses still use a credit. We keep your own records in line with SendGrid's.
• Signed events: the Event Webhook can be signed. We verify the signature on the raw body and deduplicate on each event's ID. SendGrid's event documentation does not cover retries, duplicates or ordering, so we build handlers that are safe against all three.
• API keys: a key is shown once and cannot be recovered, so we store it in the environment and give each service its own.
• Rate limits and testing: limits are per endpoint and return a 429 response with headers showing what remains. Sandbox mode validates a request without delivering it.

1. Authenticate the domain first: sending, templates and events all depend on it
2. Build templates with your team: so wording changes do not need a release
3. Handle events from day one: bounces, unsubscribes and spam reports update your own records
4. Hand over properly: the DNS records, key scopes and webhook settings documented, with notes on how to read an event