Plunk

Sending product email from a SaaS backend

Create a project, verify the sending domain and store the secret key in the backend's environment. Send password resets, receipts and notices with POST /v1/send and a transactional template, so the copy can change without a deploy. Add an Idempotency-Key to calls that can be retried, and check that the per-recipient status in the response is queued. If tracking is set to Marketing only, confirm that the transactional emails arrive without a tracking pixel or rewritten links.

Limiting repeated alerts

For alerts that fire on every request, such as a usage limit or a failing integration, call the send endpoint each time with delivery.throttle and let Plunk decide whether the recipient already had that template within the window. Add a key when one template covers several distinct alerts. Check that a throttled response returns status: throttled with nextAllowedAt, and remember that throttled calls do not update contact data, so profile changes should go through /v1/track or the contacts API.

Onboarding sequences from product events

Track events such as signed_up from the application with the public key, then build a workflow on that event: a welcome email, a delay of a few days, a condition on a contact field or event, and a follow-up or exit. Enable the workflow explicitly, because new workflows start disabled. Test with a team address first and review the execution list to see where each contact is waiting, which step failed, and whether a cancelled execution stayed cancelled.

Newsletters and product updates

Import the existing list from CSV, keeping the subscribed column so earlier opt-outs carry over, and build a segment for the audience. Write the campaign with a Marketing template so the localized unsubscribe footer is added, use Liquid conditionals for language or plan variants instead of separate campaigns, and send a test copy before scheduling. After the send, compare bounce and complaint counts with the campaign size before the next one.

Running Plunk on your own AWS account

Prepare the subdomains, an IAM user with the documented policy, the SNS topic and both SES configuration sets, then start the Compose stack and watch the /health endpoint. Request SES production access before real traffic, set DISABLE_SIGNUPS on a private instance, and keep the worker process running, because the scheduled data retention jobs run there; with SERVICE split, check that a worker container is still deployed. Back up PostgreSQL and the MinIO volume as part of normal operations.

Letting an AI agent manage email tasks

Install @plunk/mcp in the agent client with a project secret key, and start with PLUNK_READ_ONLY=true to let the agent inspect contacts, segments and campaign statistics. When write access is needed, keep the default send confirmations and leave PLUNK_ALLOW_UNCONFIRMED_SENDS unset outside headless automation. A secret key opens the whole project, so use a separate project or key for experiments.