Recommendations

Add one from the Recommendations page or with add_recommendation: the other newsletter's slug and a pitch of up to 160 characters, plain text without links. Find newsletters that want to be found in the directory or with search_recommendable_newsletters.

It is refused, with the reason, when the other newsletter:

• is in your own account. Recommendations are between different accounts, so they can't be used to grow a list in a loop;
• turned off incoming recommendations;
• doesn't ask new subscribers to confirm their email;
• has its website off, or hasn't sent its first issue, so readers would have no page to sign up on;
• can't take subscribers right now, because its account is blocked or has no plan;
• sends from an address that isn't verified yet, so it couldn't send the confirmation email.

If one of these becomes true later, the recommendation turns pending, with the reason on both newsletters' pages. It stops showing and comes back by itself when the reason is gone.

After they subscribe. Once a reader has subscribed, or has confirmed their address when the newsletter confirms signups, a “You might also like” step lists the recommended newsletters with their pitches. Nothing is ticked. The reader ticks the ones they want and presses Subscribe, and each one starts a normal signup to that newsletter: its own confirmation email, its own rules, nothing else. The reader's address is used only for the newsletters they ticked, and only with the signed proof of the signup that just happened.

On the website. A “Recommended newsletters” section on the newsletter's home page and under each issue, with links to the other newsletters' own signup pages.

In issues. Write {{recommendations}} where the block goes. It prints the list with links, in the email, the web version and the RSS feed, and nothing in it is pre-ticked. Without any recommendation showing, the tag prints nothing.

Thanks for reading.

{{recommendations}}

A newsletter takes recommendations unless its owner turns it off with set_recommendation_settings or on the Recommendations page. Its owner sees who recommends it, the pitch they wrote and how many subscribers it brought, and can decline a single recommendation with a reason, or bring it back. Turning incoming recommendations off applies at once. The recommender always sees the reason on their page: a removal never happens silently.

Listing in the directory is a separate switch, off by default. A listed newsletter shows its name, description, website and a range of subscribers such as “1,000 to 5,000”, never an exact number. Only newsletters whose website is public and that can take a signup are listed.

Each recommendation counts how many times a page showed it (once per visitor and day, with no personal data kept), how many new contacts it brought to the other newsletter and how many of them confirmed. The contact's source is recommendation:your-slug, so segments and the contacts list can filter by it. Someone who was already on the other newsletter's list isn't counted.

Limits keep it honest: 10 recommendations per newsletter, 30 additions a day per account, 300 signups a day through one newsletter's recommendation of another, and a cap per network on the signup step.

Recommendations only work between newsletters in the same region: the United States and European Union regions are separate stacks, each with its own database. A slug from the other region isn't found, and the directory lists only this region's newsletters.

list_recommendations, add_recommendation, update_recommendation, remove_recommendation, get_recommendation_stats, set_recommendation_settings and search_recommendable_newsletters work from the REST API and MCP, with the same checks as the dashboard.