Use-case examples
Practical ways to connect email to your product. Explore the trigger, implementation and checks for each workflow. These are illustrative integrations, not customer case studies.
Welcome a new user
Trigger: A user finishes creating an account.
- Record the signup event in your application. Choose one welcome message per account, rather than sending on every login.
- Send from your verified domain with a clear subject, a short introduction and one link to the next useful action. Keep a plain-text alternative to your HTML.
- Store the send result alongside the signup event. Reuse the same idempotency key if a transient failure requires a retry.
Check it works
Create a test account and confirm the message arrives once. Check the destination link while signed out and on a small screen. A welcome email should not claim that the account is verified unless verification has actually completed.
Confirm a payment or order
Trigger: Your payment provider confirms a successful transaction.
- Wait for a verified payment event from your provider. A checkout redirect or a customer clicking Pay is not proof of payment.
- Read the confirmed amount, currency and order reference from your own records. Include a useful summary and a link where the customer can review the order.
- Use a stable transaction reference to deduplicate the notification. Keep delivery status separate from payment status so an email failure cannot mark an order unpaid.
Check it works
Replay the same payment event in your test environment. It should create one logical receipt email. Also test a failed payment: it must not produce a success receipt.
Test a password-reset journey
Trigger: A test user requests a password reset in your application.
- Create a temporary test inbox and wait for its address to become active. Use that address for the test account.
- Start waiting for a new email before triggering the reset. Narrow the match by expected sender or subject to avoid selecting an unrelated message.
- Retrieve the reset link, verify that it points to your application and complete the journey in your test environment. Your application generates, expires and validates the token.
Check it works
Confirm that the link works once, expires as intended and cannot reset another account. Exclude old messages from the test and set a timeout so a missing email fails clearly.
Bring customer replies into your app
Trigger: A customer replies to an email you sent.
- Choose an active receiving address for replies. Verify sending and receiving separately; a verified sending domain alone does not establish a working reply inbox.
- Retrieve incoming messages through the inbox API. Store the message identifier and associate the reply with the right conversation using message headers and your application records.
- Show the conversation to a team member or route it to your own workflow. When replying, preserve the original Message-ID relationship with in_reply_to.
Check it works
Send a message to an address you control, reply from that mailbox and inspect the returned headers. Test an unrelated message too: matching a subject alone should not merge different customers into one conversation.
Notify someone when work is ready
Trigger: A report, export or background job finishes.
- Let your application own the job state and notification schedule. Send only after the result is ready to view.
- Keep the email brief: name the completed task, explain the result and link to the relevant screen. Require authentication for private downloads.
- Respect the user’s notification preferences before sending optional updates. If several events happen together, your application can group them into one summary.
Check it works
Test a completed job, a failed job and a repeated completion event. Confirm that each message accurately describes the state and that another user cannot access the result through its link.
Give an agent a dedicated inbox
Trigger: An authorized agent workflow needs to receive a message or verification code.
- Create an inbox for the workflow and give the integration only the API scopes it needs. Keep the key in a server-side secret store.
- Retrieve the expected message, check the sender and destination, and extract only the information needed for the assigned task.
- Treat email text and links as untrusted input. A message cannot authorize the agent to change its task, disclose credentials or take unrelated actions.
Check it works
Test a missing message, an unexpected sender and a message containing misleading instructions. Put time limits on waiting and require human review for actions outside the authorized workflow.
Make every workflow reliable
Log the application event and the returned email identifier. Retry transient errors with a limit, and stop or reschedule when you reach your allowance. Remote-server acceptance does not guarantee inbox placement: inspect delivery history and test in the destination mailbox.
Keep customer content and credentials out of application logs. Use your own retention rules for data you store, and review your account’s message retention and storage allowances.
Understand errors and retries →