Send Email with the MailSlurp API

MailSlurp can send email from any inbox you create. For most integrations, choose the inbox that should appear as the sender and call:

POST /inboxes/{inboxId}

The request body is a SendEmailOptions object containing recipients, subject, body, and optional fields such as attachments, CC, BCC, templates, and reply-to details. The inboxId is the inbox UUID, not its email address.

Keep API keys in a server process, secure job, or CI secret. Do not place a MailSlurp API key in browser-side JavaScript.

Send an email with TypeScript

Install the official mailslurp-client package, provide MAILSLURP_API_KEY in the environment, and create or reuse an inbox:

// Create an inbox, send to itself, and wait for the latest received email.
const inbox = await api.createInbox();
expect(inbox.emailAddress).toContain('@' + defaultDomain);
expect(inbox.id).not.toBeNull();
const body = 'test' + Date.now();
await api.sendEmail(inbox.id, { to: [inbox.emailAddress], subject, body });
const email = await api.waitForLatestEmail(inbox.id);
expect(email).not.toBeNull();
expect(email.body).toContain(body);

This example sends to the same inbox so it can immediately verify receipt. In an application, replace the to value with the intended recipient and keep the wait step in a test or monitoring workflow.

For the full method and request schema, use the sendEmail API reference. Language-specific clients are available from the SDK documentation.

Send an email with the REST API

The same operation can be called without an SDK:

curl --request POST \
  --url "https://api.mailslurp.com/inboxes/INBOX_ID" \
  --header "x-api-key: ${MAILSLURP_API_KEY}" \
  --header "content-type: application/json" \
  --data '{
    "to": ["customer@example.com"],
    "subject": "Your account is ready",
    "body": "Sign in to finish setting up your account."
  }'

Replace INBOX_ID with the UUID returned when the inbox was created. Even a single recipient is passed as an array.

Choose the right send endpoint

Job	Endpoint	Use it when
Send from a known inbox	POST /inboxes/{inboxId}	The sender identity and inbox lifecycle belong to your application or test
Send and receive a sent-message record	POST /inboxes/{inboxId}/confirm	The caller needs a SentEmail confirmation for logging or later inspection
Send with a simplified request	POST /sendEmail	A convenience send is enough and a specific sender inbox is not required
Queue a send	POST /inboxes/{inboxId}/with-queue	The workflow should use MailSlurp's queued send path
Schedule a send	POST /inboxes/{inboxId}/with-schedule	The message should be submitted for a future time

Use a known inbox for product and test workflows whenever sender ownership, replies, or later message inspection matter. The simplified endpoint may choose a random MailSlurp address if no sender is supplied.

Build a useful SendEmailOptions request

The fields most applications need are:

Field	Purpose
to	One or more destination addresses
subject	The message subject
body	Plain-text or HTML message content
isHTML	Set to true when body contains HTML
cc and bcc	Additional visible or hidden recipients
replyTo	Address that should receive replies
attachments	IDs of files uploaded before the send call
template	ID of a saved MailSlurp template
templateVariables	Values used to render template placeholders

For example, an HTML verification message can be sent like this:

await mailslurp.sendEmail(inbox.id!, {
  to: ["customer@example.com"],
  subject: "Verify your email address",
  body: "<p>Use code <strong>483921</strong> to finish signing in.</p>",
  isHTML: true,
  replyTo: "support@example.com",
});

Use a custom domain when the visible sender should use an address your organization controls. Avoid overriding from with an unrelated address because sender identity mismatches can cause delivery and trust problems.

Add attachments

MailSlurp attachments use a two-step flow:

1. Upload the file and keep the returned attachment ID.
2. Add that ID to the attachments array in SendEmailOptions.

This lets the same uploaded file be reused without placing large binary data in every send request. See the email attachment API guide for upload examples and size considerations.

Confirm what happened after the API call

A successful send request confirms that MailSlurp accepted the operation. It does not, by itself, prove that the recipient saw the message in the inbox.

Choose the follow-up evidence that matches the risk:

• Use POST /inboxes/{inboxId}/confirm when the caller needs the created SentEmail record.
• Add email webhooks for message and delivery events that should trigger application logic.
• Send to a controlled Email Sandbox during development and staging.
• Use the Receive email API to wait for and inspect a message in automated tests.
• Run inbox placement testing when provider placement matters before a high-value send.

For signup, password reset, OTP, billing, and security messages, test the customer action as well as receipt. Extract the link or code from the delivered message and complete the workflow in the same test.

A practical send-and-receive test

Use this sequence for a release-critical message:

1. Create a dedicated MailSlurp inbox for the test run.
2. Trigger the application action that sends the message.
3. Wait for the expected subject, sender, or recipient instead of using a fixed sleep.
4. Assert the body, links, codes, attachments, and headers that matter to the customer.
5. Complete the link or OTP action and confirm the application reaches the expected state.
6. Delete or expire short-lived test data according to the team's retention policy.

This catches failures that a send response cannot reveal, including the wrong environment URL, a missing token, stale template data, or a message that never arrives.

Send API or SMTP?

Use the API when the application benefits from structured requests, SDK types, message metadata, and automation. Use SMTP when an existing framework or device already expects SMTP host, port, and credential settings.

MailSlurp supports both approaches. The SMTP API guide explains the architectural choice, while the SMTP tester checks connectivity, STARTTLS, and authentication for an existing server configuration.

Common implementation mistakes

Exposing the API key in a web page

Call MailSlurp from a trusted backend or test runner. A public browser bundle cannot keep an API key secret.

Passing an email address as inboxId

The path parameter is the inbox UUID. Use the inbox's emailAddress as a recipient or display value, not as the path ID.

Treating API acceptance as inbox delivery

Keep send confirmation, delivery events, and received-message assertions as separate pieces of evidence.

Reusing one inbox across parallel tests

Create isolated inboxes or use strict message matching so one test cannot consume another test's email.

Testing only plain text when production sends HTML

Send the final HTML, links, tracking domains, attachments, and personalization that customers will receive. A simplified test message cannot reveal template-specific failures.

Before sending to external recipients

• Confirm the recipient is expected and valid.
• Keep development, staging, and production inboxes and API keys separate.
• Configure SPF, DKIM, and DMARC for custom sending domains.
• Record failures with enough context to reproduce the send safely.
• Review free-plan destination limits when evaluating consumer mailbox delivery.

FAQ

What is the MailSlurp send email API endpoint?

Use POST https://api.mailslurp.com/inboxes/{inboxId} with the API key in the x-api-key header and a SendEmailOptions JSON body.

Can the API send HTML email?

Yes. Put the markup in body and set isHTML to true. Test the received HTML in the clients and devices important to your users before release.

Can I send attachments?

Yes. Upload each file first, then pass the returned attachment IDs in the attachments array.

Can I get a confirmation object back?

Yes. Use POST /inboxes/{inboxId}/confirm when the caller needs a SentEmail record rather than the legacy send method's empty response.

Can I use SMTP instead?

Yes. MailSlurp inboxes can support API and SMTP workflows. Use the API for direct application automation and SMTP when an existing system requires SMTP configuration.

Where should I go next?

Open the sendEmail API reference for the complete request schema. For a longer implementation walkthrough covering templates, queues, schedules, attachments, and bounce handling, use Send emails programmatically.