Email marketing software for developers: four approaches and the tests that pick one

The first two are where most email marketing tools sit, and they are the right answer more often than developers expect. If the person who writes campaigns never opens a terminal, a platform built around their editor serves them better. The cost is the copy: every segment is only as fresh as the last sync, which is exactly the 10:30 email above.

The third is the one engineers are tempted by and should price honestly. A sending API delivers messages; it does not record consent, build the one-click unsubscribe that bulk senders now need, host a preference page or keep one suppression list (the addresses no email may go to because they bounced, complained or unsubscribed) across both kinds of mail. Each is yours to maintain, and most are a legal requirement somewhere. Build your own only for a need no provider meets.

The fourth is what Rasket is. It removes the sync and the second suppression list, and asks you to accept marketer tooling that is newer and narrower.

Each check works on any product’s trial account. The first group needs only the dashboard, so whoever chooses the tool can run it; the second needs an engineer with an API key.

This page names no products, and a typical product cannot be scored fairly without naming one, so the two middle columns hold only what follows from the approach itself and say to test it where products differ. The platform comparison scores named tools.

Four Rasket rows need more than a cell. Properties: a contact write that names a new key creates it, typed by that first value, so sending "12" first makes seats a string. Declare the property with POST /contact-properties before the first import, and a wrong-typed value is refused with 422. To fix one that already has the wrong type, PATCH its type: stored values are converted, and the change is refused while a segment or active automation filters on it (contacts reference).

Suppression: one list cuts both ways. A spam complaint about a newsletter also stops that person’s receipts and password resets until you remove the suppression (DELETE /suppressions/{id}); an unsubscribe never does.

Engagement: segments filter on contact fields, properties and topics, not on opens or clicks. The workaround takes three steps in the dashboard. Build an automation triggered on Email clicked whose one step updates the contact, setting a number property such as clicked to 1 (clicks rather than opens, because privacy features such as Apple’s Mail Privacy Protection fetch tracking pixels whether or not anyone reads the message). Then save a segment where properties.clicked exists, and another that wraps the same condition in not for people who never clicked. The property records that someone clicked, not when, so a rolling 90-day window is not possible this way. A scheduled job of yours that sends PATCH /contacts/{id} with { "properties": { "clicked": null } } (a null removes the key) gives a fixed window instead.

Templates: Rasket fills two kinds of variable, and mixing them up is the usual first bug.

Unlike Mustache, where triple braces mean “do not escape”, both kinds are HTML-escaped in the HTML body. A third form, {{brand.company_name}}, reads the brand kit; the template variables post covers all three.

One call to POST /events/send. A custom event is a name you declare first with POST /events, such as trial.started, sent for a contact who already exists. A store event needs no declaration and is one of 8 fixed names: store:product.viewed, store:cart.updated, store:checkout.started, store:order.placed, store:order.paid, store:order.fulfilled, store:order.cancelled and store:order.refunded. The Shopify app and the other store integrations send them for you, or your server does. This one records an order for flows to start from; the order confirmation itself is a transactional send through POST /emails:

curl https://api.rasket.com/events/send \
  -H "Authorization: Bearer $RASKET_API_KEY" \
  -H "User-Agent: acme-shop/1.0" \
  -H "Content-Type: application/json" \
  -d '{
    "event": "store:order.placed",
    "email": "ronald.williams@example.com",
    "idempotency_key": "order-1001-placed",
    "payload": { "order_id": "1001", "value": "64.00", "currency": "USD" }
  }'

Every request needs a User-Agent header naming your app; with none at all the API answers 403. The reply is 202 with { "object": "event", "event": "store:order.placed" } and no event ID, so log your own correlation ID. A store event for an address with no contact is kept and starts nothing; a custom event for an unknown contact is refused with 404. Rasket never creates a contact from an event.

let res;
try {
  res = await fetch("https://api.rasket.com/events/send", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.RASKET_API_KEY}`,
      "User-Agent": "acme-app/1.0",
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ event: "trial.started", email: "ronald.williams@example.com" }),
    signal: AbortSignal.timeout(10_000),
  });
} catch (error) {
  // Anything but a timeout (DNS, a refused connection) goes to your usual retry policy.
  if (error.name !== "TimeoutError") throw error;
  // A timed-out call may already be stored: log it and do not retry.
  console.error("trial.started not confirmed");
}
if (res && res.status !== 202) {
  throw new Error(`events/send answered ${res.status}: ${await res.text()}`);
}

# Once: declare the two properties the flow reads, as numbers.
for key in onboarding_started domain_verified; do
  curl https://api.rasket.com/contact-properties \
    -H "Authorization: Bearer $RASKET_API_KEY" \
    -H "User-Agent: acme-app/1.0" \
    -H "Content-Type: application/json" \
    -d "{ \"key\": \"$key\", \"type\": \"number\" }"
done

curl https://api.rasket.com/automations \
  -H "Authorization: Bearer $RASKET_API_KEY" \
  -H "User-Agent: acme-app/1.0" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Trial onboarding",
    "status": "enabled",
    "steps": [
      { "key": "start", "type": "trigger", "config": { "event_name": "trial.started" } },
      { "key": "seen", "type": "condition",
        "config": { "type": "rule", "field": "properties.onboarding_started", "operator": "exists" } },
      { "key": "mark", "type": "contact_update",
        "config": { "properties": { "onboarding_started": 1 } } },
      { "key": "welcome", "type": "send_email",
        "config": { "template": { "id": "YOUR_WELCOME_TEMPLATE_ID" } } },
      { "key": "wait", "type": "delay", "config": { "duration": "3 days" } },
      { "key": "verified", "type": "condition",
        "config": { "type": "rule", "field": "properties.domain_verified", "operator": "exists" } },
      { "key": "nudge", "type": "send_email",
        "config": { "template": { "id": "YOUR_SETUP_NUDGE_TEMPLATE_ID" } } }
    ],
    "connections": [
      { "from": "start", "to": "seen" },
      { "from": "seen", "to": "mark", "type": "condition_not_met" },
      { "from": "mark", "to": "welcome" },
      { "from": "welcome", "to": "wait" },
      { "from": "wait", "to": "verified" },
      { "from": "verified", "to": "nudge", "type": "condition_not_met" }
    ]
  }'

For an assistant that runs your marketing side, connect only the audience and marketing tools (if the protocol is new to you, start with what MCP is):

claude mcp add --transport http rasket "https://api.rasket.com/mcp?toolset=audience,marketing"

The consent screen then asks for scopes such as contacts:write, segments:write, topics:write, broadcasts:write, automations:write and events:send, and a tool exists only if you approved its scope. A campaign then takes four steps, and the third is yours:

1. create_broadcast drafts it: a segment, a sender on a verified domain, a subject and a body. Nothing is sent.
2. preview_broadcast returns what the send would do: the segment with its contact counts, recipients (its subscribed contacts), from, subject, whether every sending condition passes, the content checks, and a confirm_token with its confirm_expires_at, an hour out. Any edit to the draft voids the token.
3. Your client shows you the preview and asks. send_broadcast carries MCP’s destructive hint, so clients that honour it prompt first; keep that prompt and never set the tool to always allow. The hint is only a hint: the server enforces the token either way.
4. send_broadcast sends or schedules with the token. Without one, or after an edit, it is refused with a message telling the agent to preview again.

No tool deletes a campaign, a segment or an automation, or removes an unsubscribe. Grants are listed, and revoked, under Settings → Team → Authorized apps. send_event behaves like the API, so give a flow an agent triggers the guard above. The MCP reference lists every tool, and the MCP post covers connecting a client.

The MCP server takes only OAuth tokens that a person approved in a browser, and refuses API keys. A job that runs with nobody present, such as CI or a backend, calls the REST API with a key instead; if it only fires events, give it a sending_access key, which can send but cannot read or change definitions. Contact and automation webhooks carry svix-id, svix-timestamp and svix-signature headers, an HMAC-SHA256 over the id, timestamp and raw body, and a replay keeps the svix-id you dedupe on; the webhooks post verifies one in code.

One monthly email allowance per plan covers campaigns, automation emails and API sends. Automation runs are not billed (fair use is 250,000 runs a month, on the automations page). Contacts are billed only while subscribed to at least one topic and not suppressed.

Take a trial-onboarding product with 8,000 contacts sending 25,000 emails a month. Pro's 100,000-email tier costs $35 with 6,750 contacts included, plus 2 started blocks of 1,000 contacts at $8.80 each: $52.60 a month. The 50,000-email tier holds the emails for $20 but includes 4,500 contacts, so it comes to $55.20. The calculator on the pricing page does this for any mix; for what two named tools would cost instead, see the platform comparison.

The API’s rate limit is 10 requests a second per team, not per key, so a sync and your password resets share it, and a 429 carries Retry-After (backoff in practice). Load a list through one POST /contacts/imports rather than a request per contact: 10,000 single writes at that rate take at least 1,000 seconds.

For reputation, send campaigns from their own subdomain, such as news.acme.example, so newsletter complaints stay mostly off the name on your receipts (subdomain guide). Campaigns also go out on their own sending stream, whose bounce and complaint rates we track apart from receipts’, but both leave from our shared pool of sending IPs unless you add a dedicated IP, from the Scale plan up (warming one up).

• Teams whose marketers test every send. If campaigns live or die on A/B tests and the people running them never touch code, a dedicated marketing platform serves them better today.
• Teams that need placement tests or engagement scoring built in. Rasket reports rates and per-recipient outcomes, and engagement segments need the workaround above.
• Flows that must pause mid-run for a reply or a second event. Exit events cover “stop when they buy”; a step that waits for an event is not available.
• Event-driven flows that cannot tolerate a duplicate. Without a key on custom events, the guard above is the best available.
• Teams that require an official client library. Coming soon: the rasket package is not published yet. Until then you write requests or generate a client from the OpenAPI document.

If none of those fit, send the order event above from a free account, then follow the newsletter API walkthrough to a first campaign.