One-click approvals from email, safe from link scanners

One-click approval from email is now live in RelayWonder for three decisions: new partner applications, campaign applications and content deliveries. Each notification email carries a signed link that works for 14 days and needs no sign-in. The link opens a confirmation page that shows who applied and what they asked for; nothing changes until you press the button on that page. That extra step is deliberate. Corporate mail filters such as Microsoft Defender Safe Links scan URLs before a message is delivered [1], and the HTTP standard treats GET requests as safe so that automated retrieval and prefetching can follow them [2], so a link that approved on open could be approved by a machine. In our illustrative estimate, a brand making 48 decisions a month saves about an hour of console navigation.

What can you approve from email?

Three notifications now carry a one-click link. Each one opens a confirmation page tailored to the decision, with the facts you need to decide without opening the console.

Two details matter. For a campaign application with a quote, the accept button reads "Accept their quote" and the page shows the quote beside the campaign's default bounty, so you never accept a price you have not seen. If you want to offer a different amount, the page links to the console, where counter-offers live. For content deliveries, the page shows the result of the automatic content check (whether the page is reachable, the link and coupon are present, there is a disclosure, the brand is mentioned and the brief's question is answered) and a link to the content itself. Declining a delivery, which usually needs a note to the partner, is done in the console.

Why does the link open a confirmation page instead of approving?

The obvious design is a link that approves when clicked. It is also the wrong one, because people are not the only things that open links in email.

Microsoft's documentation for Safe Links in Defender for Office 365 says that, while Safe Links is on, URLs are scanned before the message is delivered, whether or not they are rewritten; that URLs without a valid reputation are detonated asynchronously in the background; and that a recommended setting holds messages until URL scanning finishes [1]. Other mail security products work in similar ways. A scanner that requests your approval URL to check it is, from your server's point of view, a visitor opening the link. If opening the link approved the application, the scanner would approve it, possibly before anyone at the brand read the email.

Browsers do something similar. MDN's documentation of the Speculation Rules API explains that a prefetch downloads a page with a single GET request before the user navigates, and warns that problems arise when that URL performs a server-side side effect; its examples include sign-out URLs and add-to-cart URLs [3]. An approval link is exactly that kind of URL.

The underlying rule is old. RFC 9110, the HTTP semantics standard, defines GET, HEAD, OPTIONS and TRACE as safe methods, says the distinction exists so that automated retrieval processes and pre-fetching can work, and says that a resource owner must disable or disallow an unsafe action when it is accessed with a safe method [2]. A link in an email is always a GET. So the link may show you something, but the action has to be a separate request that only a person pressing a button sends.

That is what the confirmation page does. Opening the link, whether by you, a scanner or a prefetcher, renders a page and changes nothing. Pressing the button sends the decision as a separate request. A scanner that follows the link sees a page with a button and moves on.

How signed approval links work

Each link carries a small token with four fields: the kind of decision (partner application, campaign application or content delivery), the id of the item, the id of the brand, and an expiry time 14 days after the email was sent. The token is signed with HMAC-SHA256 using a key derived from a server secret. HMAC, defined in RFC 2104, is a way to check that a message came from someone holding a shared secret key and was not changed [4]. When the link is opened, the server recomputes the signature, compares it in constant time, checks the expiry, and only then looks up the item.

Because the signature covers all four fields, changing any of them breaks the link. You cannot turn an approval link for one partner into a link for another by editing the id, or reuse a link from one brand on another brand's item. Because the expiry is inside the signed part, it cannot be extended either. After 14 days the page says the link has expired and points you to the console.

Opening the link twice is harmless, and so is pressing the button after someone else has already decided. The decision only applies if the item is still pending. If a teammate approved the partner from the console an hour earlier, the confirmation page says "This was already handled" and links to the console. There is no way to approve something twice or to flip an earlier decision from an old email.

What is the security model?

The link is the authorization. That is what makes it one click, and it is the trade-off to understand. Anyone who has the link can make that one decision on that one item until it expires or is decided. In practice the email goes only to the brand's own team, and the decisions involved are business decisions, not payments: nothing is paid out until the brand runs its own monthly payout batch. But you should treat these emails the way you treat a password-reset email and not forward them outside your team.

What the link cannot do matters as much. It cannot sign anyone in, change settings, see other partners or other items, export data, or move money; RelayWonder never holds partner money, and payouts remain monthly batches the brand pays from its own PayPal or Wise account. A leaked link exposes one decision on one item for at most 14 days. A leaked session would expose the whole console, which is why the link does not create one.

How much time do one-click approvals save?

The saving is not in the decision; reading an application takes the same time anywhere. It is in the steps around it: switching to the console, signing in if the session has lapsed, finding the right brand and the right list, and opening the item. For a decision you can make from the summary, those steps are most of the effort.

An hour a month is modest. The larger effect is on response time, which is harder to put a number on honestly. A creator who applies to your program on a Tuesday evening and hears back on Wednesday morning is still interested. One who hears back the following Monday has often moved on to the next program in their inbox. When approval is a tap from the notification, decisions tend to happen when the notification is read rather than when someone next opens the console, and partners notice.

What the partner sees after you approve

Nothing about the partner side changes, which is the point: the email is a shortcut to the same decision. When you approve an application, the partner gets an approval email with their commission terms and a link to their tracking link and coupon code, in the white-label portal if you have one live and otherwise in RelayWonder. When you accept a campaign application, the partner can start on the content at the agreed price. When you confirm a delivery, the bounty is written to the append-only ledger as a positive row, alongside any commission from the tracked link for that piece, and becomes payable on the program's normal schedule.

How to use it and when to use the console instead

1. Make sure the people who decide on partners receive the brand's partner notifications. The one-click link is in the email they already get.
2. Open the link and read the confirmation page. It shows the facts needed for a quick decision: who, what, and for campaign applications the price.
3. Press the button only if the summary is enough. For a content delivery, open the content link first and look at the content check result.
4. Use the console when you need more context: the partner's history, a counter-offer with a different amount, or a note explaining a decline of a delivery.
5. Do not forward notification emails outside your team. If one is forwarded by mistake, decide the item from the console; once it is decided, the link does nothing.

A good habit is to approve from email only when the answer is obvious and to leave anything ambiguous for a weekly review in the console. The link saves time on the easy cases, which are most of them, and the console keeps the full record for the hard ones.