Mailtrap Email Integration
SkillCommunicationA skill that guides an agent through adding transactional email sending to an application using Mailtrap's Email API. It covers bearer-token authentication, sandbox testing for dev and staging, and verifying a sending domain wi
Available today. Use it from your connected AI after setup.
No other account needed.
Have a Mailtrap account with an API token and, for sandbox testing, an inbox ID.
Then ask your AI: use the Mailtrap Email Integration skill
What your AI can do with it
- Walks through sending email via Mailtrap's Email API with bearer-token authentication
- Routes dev and staging sends to the Sandbox endpoint so test emails never reach real inbox
- Guides domain verification with SPF, DKIM, and DMARC DNS records before production sending
- Separates sandbox and production endpoints by environment
- Flags anti-patterns such as hardcoding API tokens or testing against the production endpoi
- Applies to signup confirmations, password resets, notifications, and receipts
Getting started
- Have a Mailtrap account with an API token and, for sandbox testing, an inbox ID.
- Add the skill to the agent's available skills.
- Ask the agent to implement an email-sending feature or debug email delivery in the project.
- Provide the API token through an environment variable or secrets manager, not in source code.
- Verify the sending domain's DNS records before switching from sandbox to production sending.
What this skill tells your AI
The instructions your AI receives, as published by affaan-m/ecc in skills/mailtrap-email-integration/SKILL.md and read by ahel’s review.
Patterns for adding transactional email sending to an application using Mailtrap's Email API and Sandbox, covering authentication, environment separation, and common delivery pitfalls.
When to Activate
- Implementing a "send email" feature (signup confirmation, password reset, notifications, receipts)
- Debugging why emails aren't arriving in dev/staging
- Setting up a project's first email-sending integration
- Reviewing code that calls an email API directly without sandbox separation
Core Concepts
Sandbox vs. Production separation. Mailtrap provides a Sandbox API that captures emails without delivering them, used for dev/staging so test emails never reach real inboxes. Production sending uses a separate, verified-domain endpoint. Never point a dev environment at the production sending endpoint.
Authentication. Requests use a Bearer token in the Authorization header. Tokens are scoped per project; sandbox and production typically use different tokens.
Domain verification. Production sending requires verifying a sending domain via DNS records (SPF, DKIM, DMARC) before Mailtrap will deliver to real recipients. Skipping this causes silent delivery failures or spam-folder placement.
Code Examples
// Sending via Mailtrap's Email API (production)
async function sendEmail(to: string, subject: string, html: string) {
const response = await fetch("https://send.api.mailtrap.io/api/send", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.MAILTRAP_API_TOKEN}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
from: { email: "no-reply@yourverifieddomain.com", name: "Your App" },
to: [{ email: to }],
subject,
html,
}),
});
if (!response.ok) {
throw new Error(`Email send failed: ${response.status}`);
}
return response.json();
}
// Same call, routed to Sandbox in non-production environments
const MAILTRAP_ENDPOINT = process.env.NODE_ENV === "production"
? "https://send.api.mailtrap.io/api/send"
: `https://sandbox.api.mailtrap.io/api/send/${process.env.MAILTRAP_INBOX_ID}`;
Anti-Patterns
| Anti-Pattern | Why It's a Problem | Instead |
|---|---|---|
| Using the production sending endpoint in dev/test | Real test emails reach real inboxes, risking spam complaints and leaked test data | Route non-production environments to the Sandbox endpoint |
| Hardcoding API tokens in source | Credential leak risk if committed to version control | Load tokens from environment variables / secrets manager |
| Sending before domain verification completes | Emails silently fail or land in spam | Verify SPF/DKIM/DMARC records before enabling production sending |
| No retry/error handling on send failures | Silent notification failures (e.g., user never gets password reset email) | Check response status, log failures, surface actionable errors |
Best Practices
- Keep sandbox and production tokens in separate environment variables, never share one token across environments
- Verify sending domain DNS records before any production launch involving email
- Log delivery failures with enough context to debug (recipient, template, timestamp, response code)
- Treat email sending as a fallible network call: wrap in try/catch, never assume success
Related Skills
api-and-interface-design, security-and-hardening, ci-cd-and-automation
Signals
- GitHub stars
- 268k
- Forks
- 40k
- Last commit
- Sep 2026
Questions
- When should this skill be used?
- When implementing a send-email feature such as signup confirmations, password resets, notifications, or receipts; debugging why emails aren't arriving in dev or staging; setting up a project's first email integration; or reviewing code that calls an email API without sandbox sepa
- What is the difference between the Sandbox and production endpoints?
- The Sandbox API captures emails without delivering them, so test emails never reach real inboxes. Production sending uses a separate endpoint on a verified domain and delivers to real recipients. Dev environments should never point at the production endpoint.
Advanced
- Item type
- skill
- Key
mailtrap-email-integration- Source
- github.com/affaan-m/ecc