Guide

Automate Customer Onboarding Emails

You just shipped signup and now every new user needs a welcome email, a day-2 tip, and a day-5 nudge — without buying a marketing platform. This guide drives the whole sequence from a signup hook with scheduled sends and hosted templates, all from the terminal.

Written by Hazik Director of Product Management

Reviewed by Qasim Muhammad

Verified — CLI 3.1.17 · Gmail, Outlook, IMAP · last tested June 9, 2026

What is customer onboarding email automation from the terminal?

Customer onboarding email automation is a scripted sequence of welcome messages sent over a fixed schedule after signup — a day-0 welcome, a day-2 feature tip, a day-5 check-in. Run from the terminal, each send is a single nylas email send call queued server-side, so one signup event fires all three at once.

The pattern replaces a hosted marketing tool with a few lines of shell. Marketing platforms charge per contact and add a SaaS dependency to a flow that is really three timed emails. The CLI sends over your connected provider's API, so there is no SMTP host, no contact-list import, and no monthly seat. Scheduled messages support delays from 1 minute to 30 days, which covers a typical 5-to-14-day onboarding window in a single queue. Each message is owned by the sending grant, so cancellation and status tracking stay under your control instead of a third party's dashboard.

How do I trigger the sequence when a user signs up?

Trigger the sequence by calling the CLI from your signup handler once a new account is created. Pass the user's email and name, then queue each message with a different --schedule offset. One handler invocation queues all three sends in under a second, and the provider holds them until their delivery time.

The script below is the body of an onboarding hook. It takes the new user's email and first name as arguments and queues a day-0, day-2, and day-5 message. The --schedule flag accepts relative offsets like 2d and 5d, and --metadata tags every message so you can find the whole sequence later.

#!/usr/bin/env bash
set -euo pipefail

EMAIL="$1"   # new user's email
NAME="$2"    # new user's first name
USER_ID="$3"     # your internal user id

# Day 0 — welcome, sent immediately
nylas email send --to "$EMAIL" \
  --subject "Welcome to Acme, $NAME" \
  --body "Hi $NAME, your account is live. Here's how to send your first message." \
  --metadata key1=onboarding key2="$USER_ID" --yes

# Day 2 — feature tip
nylas email send --to "$EMAIL" \
  --subject "$NAME, try scheduled sends" \
  --body "Two days in — here's a feature most people miss in week one." \
  --schedule "2d" --metadata key1=onboarding key2="$USER_ID" --yes

# Day 5 — check-in
nylas email send --to "$EMAIL" \
  --subject "How's it going, $NAME?" \
  --body "You're five days in. Reply here if anything's unclear." \
  --schedule "5d" --metadata key1=onboarding key2="$USER_ID" --yes

Tagging each send with key1=onboarding and the user id in key2 matters because metadata is set only at send time and cannot be added later. The CLI indexes keys key1 through key5 for filtering, with up to 50 pairs per message.

Why send onboarding emails with hosted templates?

Hosted templates separate copy from code, so a marketer can edit the welcome email without touching your signup script. Reference a template by id with --template-id and pass per-user values as JSON with --template-data. The provider renders the HTML server-side at send time.

The command below sends a Nylas-hosted template and fills the user.name variable from inline JSON. Templates keep the day-0 welcome consistent across thousands of signups while letting you swap copy in one place. Before going live, preview the exact rendered output with --render-only, which returns the HTML without sending a single email.

# Preview the rendered template — no email leaves the queue
nylas email send --to "$EMAIL" \
  --template-id tpl_welcome_01 \
  --template-data '{"user":{"name":"'"$NAME"'"}}' \
  --render-only

# Same template, scheduled as the day-2 message
nylas email send --to "$EMAIL" \
  --template-id tpl_daytwo_01 \
  --template-data '{"user":{"name":"'"$NAME"'"}}' \
  --schedule "2d" --metadata key1=onboarding --yes

For variables loaded from a file rather than inline, pass --template-data-file with a path to JSON. Google documents the same render-then-send model for transactional mail in the Gmail API sending guide, and the CLI delivers over that API without you writing MIME by hand.

How do I track sends and stop emails after a user churns?

Track delivery with --track-opens and list pending messages with nylas email scheduled list. When a user deletes their account on day 3, cancel their queued day-5 email with nylas email scheduled cancel so they never receive a check-in for a product they left.

This is the single most important control in the whole sequence. A churned user who keeps getting day-5 emails is a support ticket and an unsubscribe complaint waiting to happen. Because every scheduled message has an id, you cancel the exact send in one command. List the queue first to find the id, then cancel it. The 30-day scheduling window means a message queued today can sit pending for up to 720 hours, so a daily churn job that cancels stale sends keeps the queue honest.

# See every pending onboarding message
nylas email scheduled list --json

# Cancel a specific user's remaining sends by schedule id
nylas email scheduled cancel <schedule-id> --force

Add --track-opens on the welcome send to learn whether day-0 even landed, and respect one-click unsubscribe per RFC 8058 for any list-style mail. Onboarding is transactional, but giving users an exit is both courteous and required by major inbox providers.

Why run onboarding from the CLI instead of a marketing platform?

A marketing platform makes sense for newsletters with segmentation and A/B tests. A three-message onboarding sequence does not need one. Running it from the terminal removes a per-contact bill, a contact-sync job, and a webhook integration, leaving three nylas email send calls that live next to your signup code.

The infrastructure argument is stronger than the cost one. Microsoft retired Basic Auth in October 2022 and Google removed Less Secure Apps in September 2024, breaking SMTP and sendmail scripts overnight. An API-backed send survives those changes because OAuth tokens refresh automatically. The same script delivers across Gmail, Outlook, and any IMAP account, so changing the sending mailbox is a config change, not a rewrite. Microsoft documents the API send path in its Graph sendMail reference, and the CLI abstracts both provider APIs behind one command.

Next steps