> For the complete documentation index, see [llms.txt](https://docs.bloop.plus/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bloop.plus/affiliate-program/emails.md). # Email Notifications Affiliate emails keep partners moving — they confirm approval, announce tracked sales, and signal that a commission is on its way. Bloop sends these automatically across the affiliate lifecycle, from application through coupon assignment and payout. Every message is a template you can enable, rewrite, and personalise with variables. Manage them under **Branding → Emails** in the affiliate area. Each email stores its own subject, body, and button per store, plus a sender address for owner-facing notifications. > **Best practice:** Treat the registration-approved and new-commission emails as your two highest-value touches. The approval email is a partner's first impression — lead with a warm welcome and point clearly to their portal link. The payout email is what keeps affiliates promoting, so confirm the amount and thank them by name with `{{FirstName}}`. Leave the "declined" and "denied" templates off unless you have a reason to email rejections, and send yourself a test of every active template before launch so an affiliate never receives an unfilled placeholder like `{{CouponCode}}`. ### Which emails to enable, and why defaults matter Several templates ship **disabled**. A couple being off is a sensible default — but the two owner-facing notifications being off can quietly leave *you* in the dark. Walk the list deliberately before launch rather than trusting defaults. | Email | Trigger | Default | Enable it when... | | ------------------------------------- | -------------------------------------------------------- | ------- | ----------------------------------------------------------------- | | Registration pending | An affiliate signs up, awaiting review | On | Keep on — it confirms the application landed | | Registration approved | You approve an affiliate (carries activation link) | On | Keep on — it's the partner's first impression and their way in | | Registration denied | You decline an application | Off | Only if you want to email rejections; many programs leave it off | | New coupon | You assign a coupon code | On | Keep on — the affiliate needs the code to promote | | New sales | A referral order is tracked | On | Keep on — confirms tracking works, which builds trust | | Sales approved | You approve a tracked sale | On | Keep on — tells the partner the commission is confirmed | | Sales declined | You decline a tracked sale | Off | Only if you want to explain declines proactively | | New commission payout | You pay out a commission | On | Keep on — this is what keeps affiliates promoting | | Reset password | An affiliate requests a portal password reset | On | Keep on — partners can't get back in without it | | Manually added | You add an affiliate manually (invite + activation link) | On | Keep on — it's the invite | | New affiliate registration *(to you)* | A new affiliate signs up | **Off** | Enable + set a recipient if you want to know about new applicants | | New affiliate sales *(to you)* | An affiliate generates a sale | **Off** | Enable + set a recipient if you want sales alerts | The owner-facing notifications require a recipient address. If you assume Bloop is alerting you to new registrations or sales but never enabled them, applications can sit unreviewed for days. Turn them on if you rely on alerts; leave them off if you check the dashboard yourself — but decide deliberately. The "declined" and "denied" templates being off is the opposite case: a reasonable default, since not every store wants to email a rejection. Enable them only if a graceful "thanks, not this time" message fits your program. ### Affiliate emails sent to your affiliates | Email | When it sends | Default state | | --------------------- | -------------------------------------------------------------------- | ------------- | | Registration pending | An affiliate signs up and is awaiting your review | On | | Registration approved | You approve an affiliate — includes their portal activation link | On | | Registration denied | You decline an application | Off | | New coupon | You assign a coupon code to an affiliate | On | | New sales | A referral order is tracked to the affiliate | On | | Sales approved | You approve a tracked sale | On | | Sales declined | You decline a tracked sale | Off | | New commission payout | You pay out an affiliate's commission | On | | Reset password | An affiliate requests a password reset for the portal | On | | Manually added | You add an affiliate manually — invites them with an activation link | On | The registration-approved and manually-added emails both carry the affiliate's activation link. The new-sales, sales-approved, and sales-declined emails reference the specific order so the affiliate can track its status. ### Emails sent to you (the store owner) Both owner notifications ship disabled — turn them on and set a recipient address if you want them. | Email | When it sends | | -------------------------- | ------------------------------------------------------------------- | | New affiliate registration | A new affiliate signs up — includes their name, email, and any note | | New affiliate sales | An affiliate generates a new sale | These use a sender/recipient field so the alert reaches the inbox you choose. ### What good partner-facing emails say * **Open by name.** Lead with `{{FirstName}}`. A partner who sees their own name reads on; a generic "Hello affiliate" signals they're just a row in a database. * **Lead with what they care about.** The approval email should say "you're in, here's your dashboard" before anything procedural. The payout email should confirm the amount and thank them first. * **Make the next step obvious.** Every email that gives access — approval, manual-add, password reset — should point clearly at where to go. Put the link on the button, not buried in a paragraph. * **Use the right variable for the moment.** Approval and manual-add emails carry `{{AffiliateActivationLink}}`; once active, point partners to `{{AffiliatePortalLink}}`; use `{{SalesOrderId}}` on sales emails. * **Sound like your store.** Edit the default templates so the voice matches your brand, reinforcing the legitimacy your [portal](/affiliate-program/branding/portal-style.md) and [registration form](/affiliate-program/branding/registration.md) already established. ### Editing an affiliate email Open any email under **Branding → Emails** to edit: * **Subject line** — supports variables. * **Body** — the message, with formatting and variables. * **Button** — text, colour, and font (for example, the reset-password email uses a button). * **Sender** — for owner-facing notifications, the address the alert is sent to. * **Image** — an optional header image. Changes save per store and apply to every future send of that email type. ### Template variables Variables are placeholders in double braces, like `{{FirstName}}`. Bloop swaps them for real values at send time; if a value isn't available, the placeholder is left in place. | Variable | Fills in | | ----------------------------- | ----------------------------------------------------------------- | | `{{FirstName}}` | The affiliate's first name | | `{{LastName}}` | The affiliate's last name | | `{{Email}}` | The affiliate's email | | `{{CouponCode}}` | The coupon code assigned to the affiliate | | `{{SalesOrderId}}` | The tracked order (rendered as a link to the order in the portal) | | `{{AffiliateActivationLink}}` | The link an affiliate uses to activate their account | | `{{AffiliatePortalLink}}` | The affiliate's portal dashboard link | | `{{store_name}}` | Your store name | | `{{note}}` | The note submitted with a registration (owner notification) | The new-coupon email uses `{{FirstName}}` and `{{CouponCode}}`; sales emails use `{{SalesOrderId}}` and `{{AffiliatePortalLink}}`; approval and manual-add emails use `{{AffiliateActivationLink}}`. An unavailable value leaves the placeholder visible, so a test send is the only reliable way to confirm every variable resolves before a partner sees it. ### A worked example: the lifecycle a new partner sees An affiliate applies (**Registration pending** fires automatically, and if you enabled it, **New affiliate registration** alerts you with their `{{note}}`). You approve them (**Registration approved** carries `{{AffiliateActivationLink}}` as a warm welcome) and assign a coupon (**New coupon** delivers `{{CouponCode}}`). A sale tracks and gets approved (**New sales** → **Sales approved**, reassuring the partner tracking works), then you pay them (**New commission payout** — make this the warmest email of the lot, since it's what keeps them promoting). Send yourself a test of every email in this chain before launch — confirm the approval button works, the coupon code renders, and no `{{...}}` placeholder leaks through. ### Test before you go live Send yourself a test from the email editor to preview the final layout and wording. A few limits apply: * Test sends are **rate limited to 10 per minute** from the same connection. * A single test can go to **at most 20 recipients** at once. If you hit the limit, wait a moment and try again. Test emails don't affect any real affiliate record. ### Common mistakes to avoid * **Assuming everything emails someone.** The owner notifications are off by default. If you rely on alerts you never enabled, applications and sales go unnoticed. * **Shipping the default copy.** Generic templates read as automated. Edit at least the approval and payout emails to sound like your brand and open with `{{FirstName}}`. * **Skipping test sends.** It's the only way to catch an unfilled variable or a broken button before a real partner sees it. ### When and why to revisit your emails * **Applications sit unreviewed** → enable the owner registration notification and set your address so you're alerted in real time. * **You change your brand voice or program name** → re-edit the templates, especially approval and payout. * **You start handling declines proactively** → enable the "denied" and "sales declined" templates and write them to be gracious. * **A partner reports a confusing email** → send yourself a test of that template; an unfilled variable or misordered message is usually the cause. ### Related * [Affiliate settings](/affiliate-program/settings.md) — payment methods and broader email configuration. * [Affiliate sales](/affiliate-program/sales.md) — approving and declining the sales these emails announce. * [Affiliate payouts](/affiliate-program/payouts.md) — paying commissions, which triggers the payout email. * [Email sender domain](/account-and-settings/email-sender.md) — send these emails from your own branded domain. * [Affiliate program setup](/quick-start/getting-started-1.md) — approving registrations and assigning coupons. * [Recruiting affiliates](/best-practices/recruiting-affiliates.md) — a professional email lifecycle is part of attracting and keeping good partners. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.bloop.plus/affiliate-program/emails.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.