Email Architecture

This guide describes email from the integrator's side of the boundary: which Platform events produce email, to whom, from what sender identity, how the same events reach your systems as webhooks so you can run your own workflows, and where notification settings live. One boundary rule up front: transactional and account email is sent by the Platform, from the Platform's domains, using the Platform's templates. Account holders do not send Platform email through the API, and there is no endpoint that accepts a message for delivery: if your integration needs to communicate with a buyer about an order, it does so through its own channels, under the consent rules below, or not at all.

Which events produce email

Email on the Platform is event-driven: a defined event produces a defined message to a defined recipient. The principal events, from an account holder's viewpoint

• Order placed / payment confirmed: the buyer receives an order confirmation and receipt: the lines as charged, the totals, and the delivery address, matching the order record (Orders).
• Shipment reported: when you report a shipment with tracking (Fulfillment), the buyer receives the shipping notification with the carrier and tracking for that parcel. A second parcel produces its own notification; this is one reason shipment reporting must be accurate and prompt: the email is generated from your report.
• Delivery and exceptions: delivery confirmation, and notices when a shipment hits a stated exception the buyer must know about.
• Returns milestones: the buyer receives the return authorization and instructions, the receipt confirmation, and the refund confirmation as the return moves through its states (Returns).
• Refunds: a refund confirmation stating the amount and the original payment method it returns to (Payments).
• Account events for your staff: the notices your own team relies on: new-order alerts, return requests awaiting action, standing and program notices (Governance), and payout notifications, delivered to the addresses your account designates.

If an event is not on this list, do not design a workflow that assumes an email exists for it: and if a buyer tells your team "I never got the email," the order and return records in the API are where the underlying facts are checked, because the email is a rendering of those records, never the record itself.

The same events as webhooks

Every event that produces a buyer or staff email is also a Platform event your integration can receive directly, as Webhooks describes and Webhook Event Schemas defines. Build on the webhook, not on the email

• Your systems should react to the webhook event: order paid, shipment reported, refund issued: and run your own workflows (warehouse tasks, accounting entries, your CRM) from it.
• Never use inbound email as an integration input: do not parse confirmations, scrape inboxes, or trigger processes from messages. Email is a human channel; the webhook is the machine channel, with signatures, retries, and idempotent delivery that email does not have.
• Conversely, do not duplicate the Platform's email with your own. A buyer who receives the Platform's shipping notice and your system's near-identical copy learns to distrust both; your webhook-driven communications should be the ones the Platform does not send: your internal alerts, your staff tasks, your own service messages under your own identity.

Sender identity

• Platform email is sent from the Platform's verified domains, under the Platform's name, with the Platform's templates and legal footer. It presents your account's information: your seller name, your order details: inside that frame, as the marketplace's message about your sale.
• Your integration cannot change the sender, the template, or the branding of Platform email, and cannot send mail "as the Platform" from your own systems. Representing your mail as Platform mail is a serious policy violation (API Policies).
• Your own mail: to your staff, and any buyer communication your account is permitted to send under its own identity: comes from your domains, under your name, with your own consent records. The two streams must stay visibly distinct to the recipient.
• Sign-in and account-recovery email belongs to the account system and is separate from everything in this guide; integrations never send it, trigger it, or imitate it.

Where notification settings live

Notification preferences: which staff addresses receive account alerts, which buyer notifications an account's program includes, and buyers' own channel preferences: are managed in the Seller Center and the account's program settings, not through the API. Working rules

• Set staff alert addresses deliberately and keep them current; an alert stream delivered to a departed employee's inbox is an operational blind spot and a data-protection problem.
• Buyer preferences (for example, opting out of non-essential messages) are recorded with the Platform and honored by its sending. Your integration neither overrides nor second-guesses them, and any marketing your account sends under its own identity requires its own recorded opt-in, separate from transactional mail (Systems Integrations).
• Transactional messages: receipts, shipment and refund notices: are not marketing and do not require opt-in; the buyer needs the record of their transaction. They also carry no marketing content. Keep that separation absolute in anything your account sends under its own identity as well.

Deliverability is partly your data quality

The Platform's sending reputation is shared infrastructure: bad addresses imported through integrations degrade it for everyone. Your part

• Validate email addresses in your own systems before they are attached to orders, accounts, or staff alerts.
• Never supply purchased, scraped, or guessed address lists into any Platform-adjacent flow.
• If your staff-alert or account addresses start bouncing, fix them at the source; repeated hard bounces to an address get it suppressed, including for alerts you actually need.

Failure handling

• A buyer reports a missing notification: verify the underlying event first (the order state, the shipment report, the refund record). If the event happened, the message was generated from it; check the address on the order for error before suspecting delivery. If the event never happened: most commonly, a shipment never reported: the missing email is a symptom, and the fix is in Fulfillment.
• Your webhook-driven workflow fired but no email reached the buyer: these are separate channels by design; the webhook proves the event, not the message. Check the event record, then raise delivery questions with support@aapawz.com quoting the order id and the event.
• Duplicate notifications reported: almost always two senders: the Platform, and an integration duplicating it. Find the second sender in your own systems and stop it.

What good looks like

Your integration reacts to webhooks, lets the Platform send the Platform's email from the Platform's domains, keeps its own mail under its own identity with its own consent records, and keeps the addresses it controls valid and current. Email stays what it should be: a trustworthy rendering of events that your systems already know about through the channel built for machines.

Questions about notification email: support@aapawz.com.