## Schedule and cancel transactional emails
1. Only schedule mail whose content is final at schedule time. If the order total or appointment time can still change, send at event time instead of scheduling; a stale scheduled mail is worse than a late one.
2. Schedule through the `scheduled_at` field on the send call with a natural time string. You get back a scheduled event and can watch for the `email.scheduled` webhook to confirm it landed. Docs: https://resend.com/docs/dashboard/emails/schedule-email
3. Store the scheduled email id in your own database keyed by the business entity, for example the appointment id. Without that mapping you cannot cancel later.
4. When the underlying event changes or cancels, call the cancel endpoint with the stored email id before the send time. Verify the cancellation in the dashboard; a cancelled email must not appear as sent.
5. If your code retries a schedule call, use an idempotency key so a retried worker does not create two scheduled copies of the same reminder.
6. Build a sweeper that reconciles scheduled ids against your business state daily: any scheduled mail whose entity no longer qualifies gets cancelled. This catches the cases your event handlers missed.
7. Test the full cycle in staging: schedule, confirm the scheduled event, cancel, and assert nothing delivers. Do this before relying on cancellation in production.