Skip to content
cccskills
FreePublished on GitHub

mailtrap-email-integration

Guides implementation of signup confirmations, password resets, and other application emails through Mailtrap. Covers API authentication, verified sending domains, separate testing environments that capture messages without delivery, and handling failed send requests.

OriginalShow the original description

Guides agents through integrating transactional email sending via Mailtrap's Email API, including sandbox testing, domain verification, and API authentication. Use when implementing email-sending features, debugging delivery issues, or setting up safe dev/staging email testing.

See how to install

Good for

  • Adding signup confirmation emails
  • Implementing password reset emails
  • Testing emails without sending them to real inboxes
  • Investigating delivery failures

Files included (1)

  • SKILL.md3.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Mailtrap Email Integration

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

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

accessibility

FreeSummary

Design and audit interfaces for Web, iOS, and Android using WCAG 2.2 accessibility guidance. Check screen-reader labels, keyboard navigation, contrast, and control sizes to identify barriers and guide implementation for people using assistive technology.

  • Adding descriptive labels to icon-only buttons
  • Reviewing keyboard navigation and modal focus
  • Checking contrast and control sizes
affaan-m/ECC283.3KUpdated Oct 16, 2026

Investigate unreliable AI agents across 12 layers, including instructions, memory, tool execution, and display. Use code and logs to trace failures, rank findings by severity, and produce an ordered repair plan that prioritizes code changes.

  • Investigating failures that appear only inside an agent application
  • Tracing old conversation content leaking into new sessions
  • Checking skipped or falsely claimed tool execution
affaan-m/ECC283.3KUpdated Oct 16, 2026

agent-eval

FreeSummary

Compare coding agents on tasks from your own codebase. Define success checks, run agents in separate Git working directories, and report pass rates, available API costs, completion time, and consistency across repeated trials.

  • Comparing coding agents on real development tasks
  • Evaluating a new tool or model before adoption
  • Checking performance after agent updates
affaan-m/ECC283.3KUpdated Oct 16, 2026

Design and refine an AI agent’s available actions, tool inputs, and result formats. Define recovery steps for errors, manage the information kept in context, and evaluate changes through completion rates, retries, and cost per successful task.

  • Define an AI agent’s tool set and input formats
  • Make tool results and next steps easier to interpret
  • Specify safe retries and stopping conditions
affaan-m/ECC283.3KUpdated Oct 16, 2026

Diagnose failed AI agent runs by capturing errors, checking likely causes, and choosing small, reversible recovery actions. The workflow produces a structured report of the failure, recovery steps, and evidence, helping explain repeated retries or stalled progress.

  • Diagnosing repeated tool calls with no progress
  • Investigating quality loss as context grows
  • Checking file paths and environment mismatches
affaan-m/ECC283.3KUpdated Oct 16, 2026

Diagnose AI agent runs that fail repeatedly, loop through tools, or lose track of the task. Capture errors and environment details, test a focused recovery action, and produce a report explaining the evidence and outcome.

  • Diagnosing repeated failures in an agent run
  • Investigating loops through the same tool calls
  • Reviewing output degradation as context grows
affaan-m/ECC283.3KUpdated Oct 5, 2026

See all skills by affaan-m

Report a problem with this skill