> 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/affiliates.md). # Managing Affiliates Who you let in matters more than how many apply. A focused roster of partners whose audience overlaps your customers will out-earn a crowd of casual sign-ups — and it spares you the work of reviewing sales from people who were never going to convert. Managing affiliates in Bloop comes down to two repeating decisions: who to bring on, and whose link stays live. This page covers affiliate statuses, how to recruit (manual add or self-registration), how to evaluate and approve or reject applicants, a worked example, exporting your list, common mistakes, and "login as" portal preview. Open the **Affiliates** tab to see your full roster, each affiliate's status, their assigned campaign, referral link code, and performance. > **Best practice:** Approve for fit, not just volume. Check that an applicant's audience plausibly buys what you sell — a relevant partner with a small following usually drives cleaner sales than a large but mismatched one. Use the **pending** queue as a real gate, and keep strong performers on a higher-rate [campaign](/affiliate-program/campaigns.md) so they have a reason to keep promoting. The full playbook is in [recruiting and approving affiliates](/best-practices/recruiting-affiliates.md). ### Affiliate statuses An affiliate is always in one of three statuses: | Status | Meaning | What to do | | -------- | ------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | Pending | Applied (or was created as pending) and awaiting review. Cannot earn yet. | Evaluate and approve or reject. Don't leave applicants waiting — a stale queue loses good partners. | | Approved | Active. Their referral link is live and orders generate commissions. | Monitor performance; move your best to a higher-rate campaign. Reject only if they go inactive or break terms. | | Rejected | Declined. Their link does not earn commissions. | Leave as-is, or set back to approved to reinstate a partner who has since become a good fit. | There is no separate "paused" status. To stop an affiliate from earning, move them to **rejected**; to reinstate them, set them back to **approved**. Each status change triggers an email to the affiliate (registration pending, approved, or denied), so they always know where they stand. Approving someone makes their link live immediately — treat the approval click as the real gate rather than clearing the queue on autopilot. ### How to recruit affiliates Two paths into your program: * **Manual add** — for partners you already know: creators you reached out to, existing customers with an audience, agencies you have a relationship with. Vetting happens before they enter Bloop. * **Self-registration** — for scale. You publish a form, applicants come to you, and your approval step becomes the filter. Most healthy programs use both: manual add to seed strong partners at launch, then self-registration to grow once you have proof the program converts. ### Adding affiliates manually 1. In the **Affiliates** tab, choose to add a new affiliate. 2. Enter their first name, last name, and email. 3. Assign them to a campaign. The affiliate gets a unique referral link code and a notification email. Because you chose them, there is no pending review step. ### Self-registration Share your registration form and let affiliates apply on their own. Applicants land in your dashboard with **pending** status, ready for review. Form fields are configured in [affiliate settings](/affiliate-program/settings.md). Self-registration scales recruitment, but makes your approval step the quality gate — keep it deliberate. Asking for an audience link, audience size, and a promotion plan turns a blind approval into an informed one. ### How to evaluate an applicant Judge pending applications on fit before reach: 1. **Audience overlap.** Does their audience plausibly buy what you sell? A skincare creator for a skincare store beats a generic deals account ten times the size. 2. **Promotion plan.** How do they intend to drive traffic — content, email, social, coupon sites? A clear, on-brand plan is worth more than a vague one with big numbers. 3. **Reach, in that order.** Audience size matters, but only after overlap and plan check out. 4. **Brand safety.** Spammy coupon farming, off-brand content, or undisclosed affiliate behaviour is a reason to reject regardless of reach. ### Approving and rejecting * Open an affiliate and change their status to **approved** or **rejected**, or * Select several affiliates and apply a **bulk status** change. Approving activates the referral link immediately. Bulk actions send the matching status email to everyone selected — useful for clearing a backlog, but check the selection first so a borderline applicant doesn't slip through. ### A worked example: vetting one application *Illustrative.* "Maya" applies with her Instagram link (\~8,000 coffee-enthusiast followers) and a note about weekly bean reviews — strong audience overlap, a credible on-brand plan, clean content. You **approve** and assign her to your standard campaign, using **login as** to confirm her portal before she starts sharing. Contrast an applicant with no audience link, a vague "I'll share with my network" plan, and a coupon-site URL: **reject**, since the likely result is low-intent traffic you'd have to scrutinise later. ### Exporting your affiliates Export your roster to CSV from the **Affiliates** tab. The export includes first name, last name, email, status, assigned campaign, referral link code, discount coupon, join date, and any custom registration attributes. Export the full list or filter by status first. There is no bulk CSV import — affiliates join by manual add or self-registration only. ### "Login as" — preview the affiliate portal Use **login as** from an affiliate's record to open their portal session and see exactly what they see. Useful for verifying their dashboard, troubleshooting a reported issue, or confirming branding before going live. A demo portal is also available without selecting a specific affiliate. ### Referral links and coupons Every approved affiliate has a unique referral link code, generated automatically. You can also assign a personal **discount coupon** so they can offer customers a deal. Bloop prevents assigning a coupon already used by another affiliate or tied to a campaign, and notifies the affiliate when a new coupon is set. ### Common mistakes to avoid * **Approving on reach alone.** A big following with no audience overlap sends low-intent clicks. Approve for fit first. * **Treating the pending queue as a rubber stamp.** If you approve everyone, the gate does nothing. Use it as a real filter. * **Letting the queue go stale.** Good applicants lose interest. Review on a regular cadence. ### Related * [Getting started with affiliates](/quick-start/getting-started-1.md) — program overview. * [Affiliate campaigns and commissions](/affiliate-program/campaigns.md) — what each affiliate earns. * [Affiliate sales tracking](/affiliate-program/sales.md) — the orders each affiliate drives. * [Recruiting and approving affiliates](/best-practices/recruiting-affiliates.md) — the strategy behind the gate. --- # 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/affiliates.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.