Reader submissions

Readers can send you links. Every newsletter website can carry a submit page, and what arrives lands in your library as a suggestion: nothing a reader sends is ever published, or added to an issue, on its own.

Turning submissions on or off

Accepting submissions is on by default, and the toggle is in Settings, then Website, then “Accept link submissions”.

With it on, the page is live at /submit on your newsletter’s address, a “Submit a link” link appears in your website footer, and the page is listed in your sitemap so search engines can find it. Turning it off removes all three: the page returns a 404, the footer link goes, and so does the sitemap entry. The setting belongs to the newsletter, so you can accept submissions on one and not on another.

What a reader is asked for

Four fields, one of them required. The link is required and has to be an ordinary web address. “Why is it good?” is a free-text box of up to a thousand characters. Their name and their email are both optional, and the page says what they are for: crediting them if you run it.

The form asks nothing else, and the fields are not configurable. That is a deliberate limit rather than an omission, because a suggestion form is competing with the reader closing the tab, and the page already tells them the honest position, that every suggestion gets read and not everything makes it in.

What happens to a submission

A submission becomes an item in your library inbox, labelled as a reader submission, with the reader’s name beside it and their reason as the note.

It appears in an issue when you insert it and not before, which is the whole design: you choose the section, you write the title, and the take in your issue is yours rather than theirs. Issue Mint does not read the linked page for a submission, so the row shows the address itself rather than a title until you fill one in.

Nothing goes back to the reader

Issue Mint never emails a submitter. There is no thank-you, no confirmation and no notice if their link runs.

Submitting also does not subscribe anybody: the address sits on the library item so you can credit or reply to a person yourself, and nothing else happens to it. If crediting readers matters to you, and for most newsletters it is worth more than the link, do it in the note you write on the link or in your intro.

One digest a day, not an email per submission

Issue Mint emails you once a day per newsletter, at 08:00 UTC, with what has come in since the last digest.

The email lists up to twenty items, says how many more there are beyond that, and its button opens your newest draft, or your issue list when nothing is open. Every item appears in exactly one digest, and a day with nothing new produces no email at all. The weekly summary carries the slower signal: how many reader submissions are still sitting in your inbox unused, which is the number that grows quietly while you are busy.

Keeping the rubbish out

Three things sit in front of the form: a hidden field that bots fill in and people do not, a rate limit of five submissions a minute and fifty a day from one address, and optionally a Cloudflare Turnstile challenge.

A submission that trips the hidden field gets the same thank-you page as a real one and is not saved, because telling a bot that it failed teaches it to try again. The rate limit is shared with the subscribe and sponsorship forms on the same site, so it is a limit on one visitor rather than on your website. Turnstile is a platform setting rather than one of yours, which means there is no key for you to obtain and nothing to configure.

What it is not

The submit page is a suggestion box, not a contributor system. Readers cannot write copy that appears in your issue, cannot edit anything, cannot see what other people have sent and cannot see whether their link was used.

Everything a reader sends passes through your hands, and the website every newsletter gets carries the page without you building or hosting anything.