Send and receive email in Make with Shipmail

Before you start

• A Shipmail mailbox on your domain, like agent@yourdomain.com. Everything the scenario sends shows up there, and your team can read it.
• An API key from Developer, then API keys, limited to that mailbox. Sending and replying need messages:send. If a person should approve every email first, start with the Draft only preset instead (see the end of this guide). Scopes are on API authentication.

Send an email

Add the HTTP app's Make a request module and fill it in as below. Leave Authentication type on No authentication, because the key goes in the Authorization header.

{
  "from": "agent@yourdomain.com",
  "to": ["jane@customer.com"],
  "subject": "Your order has shipped",
  "text": "Hi Jane, your order is on its way."
}

Map values from earlier modules into the JSON in place of the sample values. Shipmail answers 201 with the message. Use a sm_test_ key while you build: Shipmail accepts the request and delivers nothing (sandbox mode).

Receive email with a Custom webhook

Start a new scenario with Webhooks, Custom webhook. Next to Webhook, click Add, give it a name, and set Get request headers to Yes in the advanced settings, so the scenario can read the Authorization header. Save, and copy the URL Make creates.

Then create the Shipmail webhook. In the dashboard, open Developer, then Webhooks, and choose Create webhook. Paste the Make URL as the Endpoint URL, pick message.received, limit it to the mailbox, and put Bearer followed by a long random string in Authorization header. Turn on Include reply text to get what the sender wrote, and Authenticated senders only to skip mail that failed DMARC. Or create it with a key that has webhooks:write and is not limited to a mailbox:

curl -X POST https://shipmail.to/api/v1/webhooks \
  -H "Authorization: Bearer sm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "WEBHOOK_URL_FROM_MAKE",
    "events": ["message.received"],
    "mailbox_ids": ["MAILBOX_ID"],
    "authorization": "Bearer YOUR_RANDOM_STRING",
    "include_reply_text": true,
    "authenticated_senders_only": true
  }'

While the module waits for data, send an email to the mailbox, so Make has a real event to map from. The event format is on webhooks.

Reject requests without your value

Anyone who learns the Make URL can post to it. Click the line after the Custom webhook to add a filter, and map the value of the authorization header from the webhook's headers into the first condition. The second condition skips the webhook.test event that Send test event delivers.

Make's own API key option on the webhook expects an x-make-apikey header, which Shipmail does not send, so use the filter.

Checking X-Shipmail-Signature as well is possible but fiddly. Make's sha256 function returns an HMAC when you give it a key, and the webhook's JSON pass-through setting hands you the body as text. You would build v1=, the timestamp, a newline and the body in a formula, and compare the result with the header (webhook verification). For most scenarios the Authorization filter is enough.

Answer at once and drop duplicates

Shipmail waits 10 seconds for a 2xx answer. Without one, it retries after 1 minute, 5 minutes, 30 minutes and 4 hours, and disables the webhook after 5 failures in a row. Without a Webhook response module, Make answers 200 as soon as the request is in its queue. Do not add a Webhook response at the end of a long scenario: Make can wait up to 180 seconds for it, and Shipmail gives up after 10.

A retry still happens when the network drops an answer, and then the scenario runs twice. The event_id is the same on every retry. Record each one you handle in a Make data store, and stop when it is already there.

Reply to the sender

End the scenario with another Make a request module. The reply goes to the exact message that arrived, so it stays in the same conversation. Map the webhook's fields where the angle brackets are. to is required.

{
  "to": ["<data.from.address>"],
  "text": "Thanks for your email. We will get back to you within one business day."
}

The idempotency key comes from the email ID, so a replayed event cannot send a second reply (idempotency). Treat the email's text as untrusted input when you pass it to an AI module: it was written by someone outside your company.

Related guides

• Send and receive email in n8n and in Zapier
• Receive email in an AI agent, for sender checks and conversation memory
• Transactional email, for app email from a sending subdomain

Frequently asked questions