Mailtrap Email Integration

SkillCommunication

A 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.

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

  1. Have a Mailtrap account with an API token and, for sandbox testing, an inbox ID.
  2. Add the skill to the agent's available skills.
  3. Ask the agent to implement an email-sending feature or debug email delivery in the project.
  4. Provide the API token through an environment variable or secrets manager, not in source code.
  5. 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-PatternWhy It's a ProblemInstead
Using the production sending endpoint in dev/testReal test emails reach real inboxes, risking spam complaints and leaked test dataRoute non-production environments to the Sandbox endpoint
Hardcoding API tokens in sourceCredential leak risk if committed to version controlLoad tokens from environment variables / secrets manager
Sending before domain verification completesEmails silently fail or land in spamVerify SPF/DKIM/DMARC records before enabling production sending
No retry/error handling on send failuresSilent 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