Discord Activities Run HTML5 Games in an iframe. Your Licensed Build's First External Request Returns blocked:csp.
Discord Activities run HTML5 games inside an iframe, which makes them look like a drop-in distribution channel for a licensed catalogue. They are not.
The pitch writes itself. You already own web builds. Discord already runs web builds. Point one at the other and you have a new channel at zero marginal cost. Every part of that sentence is true except the last four words.
🎮 The Surface Is Real, and It Is Bigger Than Most Portals You Are Chasing
Worth establishing this before picking it apart, because the constraints below are only interesting if the channel is worth the argument.
Discord's developer blog post Come Build Where the World Plays (26 September 2024) is the announcement that opened Activities to all developers. The numbers it cites: 200 million monthly users, over 1.5 billion hours of gameplay per month, roughly 90% of monthly users engaging with gaming, and more than 25% of monthly active users already using Discord apps. It also shipped the App Launcher, which is the discovery surface — users find Activities from inside text and voice channels rather than from a store page.
That 200 million figure has not moved in Discord's own communications. The company's press release of 9 February 2026 announcing global teen-by-default settings still cites 200 million monthly active users. Third-party trackers put the number higher — estimates in the 250–260 million range circulate widely — and they disagree with each other as much as they disagree with Discord. Use the company's own number. It is the conservative one and it is the one Discord will defend.
So: a genuine HTML5 audience, in the same order of magnitude as a mid-sized carrier portal, with distribution built into a social graph instead of bolted onto a landing page. Good. Now the part the deck skips.
🧩 An Activity Is Not a URL You Hand Over
Discord's own documentation defines an Activity as "a web app hosted in an iframe that use the Embedded App SDK to communicate with Discord clients." Read the second half of that sentence twice. The SDK is not a nice-to-have for analytics. It is the mechanism by which the iframe learns which channel it is in, who is in it, and when the session ends.
Practically, shipping an Activity means the game's own code initialises the SDK, completes a ready handshake with the Discord client, runs an OAuth flow to identify the participant, and subscribes to instance lifecycle events. None of that is configuration. All of it is code inside the game bundle.
Compare that to how you ship to every other channel a licensed catalogue serves. A portal takes a URL. An aggregator takes a folder. A telco takes a feed and an iframe. In all three cases the deliverable is the build you were licensed, unmodified. Discord is the first mainstream HTML5 surface where the deliverable is an integration.
Which surfaces a licensing question most catalogue buyers have never had to ask: do you have the right and the means to modify the build? A standard non-exclusive HTML5 licence often delivers a minified bundle plus assets, with distribution rights and no source. That is fine for a portal and useless here. If Discord is on your roadmap, the deal you need is a source-code arrangement, not a distribution licence — and that is a different price and a different negotiation.
🚧 blocked:csp Is the First Error You Will See
Assume you cleared the source problem. Now the sandbox.
Discord's Activities networking guide is blunt about it: Activities are sandboxed behind a Discord proxy built on Cloudflare Workers, and everything the Activity loads resolves under https://{clientId}.discordsays.com. Requests to domains you have not declared do not degrade. They fail. The documentation's own example: "if your application has an npm module that attempts to make an http request to https://foo.library.com, the request will fail with a blocked:csp error."
The escape hatch is URL Mappings, configured per app in the Developer Portal as PREFIX/TARGET pairs — map /api to some-api.com, then have the game request /api/endpoint instead of the absolute URL. The rules around it are fiddly in ways that will cost you an afternoon each time: omit the protocol from targets, point targets at directories rather than files, and order longer prefixes before shorter ones so /foo/bar is not swallowed by /foo. For third-party libraries whose URLs you cannot edit, the SDK exposes patchUrlMappings to rewrite them at runtime. Cookies must match the full discordsays.com subdomain and carry SameSite=None; Partitioned. WebSockets work. WebRTC does not.
Now count the outbound calls in a real licensed build
This is the step that turns a technical footnote into a budget line. A typical third-party HTML5 casual title reaches off-domain for more things than its licensor's spec sheet suggests:
- Assets or audio served from the licensor's CDN rather than bundled
- A silent analytics ping back to the developer's own endpoint
- A leaderboard or high-score service
- Google Fonts or a similar font host
- An ad tag, if the build shipped monetised
- A "more games" cross-promotion panel pointing at the licensor's portal
Every one of those is a domain you must discover, declare, and map. Several will be hardcoded deep inside a bundle. And the cross-promotion panel is worse than a technical problem: it is a link out of your Activity into someone else's traffic funnel, sitting inside a Discord app published under your name. Removing it is a contractual question, not an engineering one, and permission to strip licensor branding and outbound links is not automatic — read the clause before you promise anyone a launch date.
The economics follow directly. This is per-title work. It does not amortise across a catalogue, because every title has a different set of outbound domains and a different bundle to unpick. Anyone modelling Discord as "we already have 1,000 games, so we have 1,000 Activities" has the unit of work wrong by three orders of magnitude.
👥 Discord's Own Design Docs Rule Out Most of a Casual Catalogue
Even with source and a clean network map, most of what sits in a licensed catalogue is the wrong shape for this surface — and you do not need to guess at that, because Discord published it.
The platform's Activities design patterns guide leads with "Interaction over Isolation": user actions should affect the other participants. It states that small groups of roughly 3–8 people show more engagement and retention than single-player experiences. Solo play gets a named fallback pattern — "Solo-Plus", meaning playable alone but genuinely better together — which is the documentation's polite way of saying single-player is tolerated rather than served.
The instance model reinforces it. An Activity runs as an instance tied to a channel, a fresh one is created on each launch, and the instance closes when the last participant leaves. There is no persistent session that a lone player returns to. The surface is built around a group forming, playing, and dispersing.
A licensed casual catalogue is the inverse of that. It is overwhelmingly single-player, short-session, score-based, with no shared state and no concept of another participant. Discord does not prohibit any of it. It simply gives it nothing: no discovery advantage, no retention loop, no reason for the second person in the voice channel to care.
My read, and it is a read rather than a measurement: a 1,000-title casual catalogue contains maybe a couple of dozen candidates worth porting, and they are the ones that already have turn-based structure, head-to-head scoring, or a shared board. Card games, word games, quiz formats, pool and darts, drawing games. Everything that already looks like the built-in Activities — Poker Night, Sketch Heads, Blazing 8s — because those are the shapes Discord's own product team converged on.
💰 The Money Is Not Where a Portal Operator Expects It
Discord's documented monetization path for Activities is in-app purchase: you define SKUs, users buy durable or consumable items or a subscription, and your backend verifies entitlements through the Discord HTTP API rather than trusting the client. At the September 2024 launch, IAP was live for users in the US, UK and EU on desktop, with regional expansion stated as planned — worth re-checking current availability against your target markets rather than assuming it has gone global.
On revenue share, be careful. Discord's public Activities and monetization documentation does not state a headline percentage, and the secondary sources disagree: some write-ups report a 10% platform fee on Activity in-app purchases, others describe an 85/15 split up to a revenue threshold with 30% above it. Those are not reconcilable. Treat the number as something you confirm in writing with Discord before it goes anywhere near a model, and do not let a 10% figure lifted from a blog post carry a business case.
The structural problem is bigger than the percentage. There is no display or rewarded ad stack here. Discord's Ads Policy governs advertising on the platform including within Activities, and its Developer Policy bars disclosing API data to advertising networks, data brokers, or monetization services. If your catalogue's entire revenue model is an ad tag — and for most portal and telco operators it is — you arrive at Discord with no revenue model at all, only a build cost. IAP means designing purchasable items into games that were never built to sell anything, which is again source-level work. If your ad stack is the whole plan, that constraint is worth understanding properly before you spend anything here; it is the same analysis that governs how a licensed catalogue earns anywhere else.
🔞 The Audience Is 13+, and the Young End Is Getting Harder to Reach
Discord's minimum age is 13. That alone removes preschool and young-children content from consideration, which is a meaningful slice of most licensed catalogues and most branded-character work.
The safety layer on top has been moving fast. Discord introduced age assurance for UK and Australian users during 2025, with the Australian rollout beginning 9 December 2025, in response to the UK's Online Safety Act and Australia's social media minimum age legislation. Per the company's 9 February 2026 press release, teen-by-default settings then began rolling out globally in early March 2026: sensitive content blurred by default, age-restricted channels and servers closed to unverified accounts, and adult verification required to change certain settings. Discord's stated position is that over 90% of users are never asked to verify anything, because background age inference handles the classification.
Separately, Discord's Ads Policy prohibits advertising intended solely for an audience below 13. So the kids' end of a catalogue is excluded twice over — once by the platform's age floor, once by what you would be allowed to run against it.
The catalogue that fits Discord is teen and adult, competitive, and social. That is a different selection from the one that fits a carrier deck, and a very different one from the one that fits a children's HTML5 games portal. Treating Discord as another destination for the same feed is the mistake.
🧭 What I Would Actually Do
- Do not port the catalogue. Pick three to five titles with real multiplayer, turn-based play, or head-to-head scoring. Everything else fails Discord's own design guidance before it fails anything technical.
- Confirm you can modify the build. Source code or a documented right to alter and rebuild. Without it the SDK integration is impossible and the rest of the list is moot.
- Enumerate every outbound domain before you estimate. Open the network tab, load the title, and write down every host it touches. That list is your URL Mappings work and it is the single biggest driver of per-title cost.
- Resolve the cross-promotion panel contractually. Either you have written permission to remove licensor links and branding, or you do not ship that title as an Activity.
- Budget it as product development, not distribution. A distribution deal costs a contract and a feed. This costs engineering time per title, indefinitely, because Discord's client keeps moving.
- Get the commercial terms in writing. Revenue share, supported purchase regions, payout mechanics. None of it should come from a secondary source.
If that list reads as discouraging, it is not meant to. It is meant to reprice the opportunity honestly. Discord is a good channel for a small number of well-chosen, socially-shaped titles that someone owns properly. It is a bad channel for a licensed catalogue used as a catalogue.
🌲 Where This Lands for a Licensing Buyer
Forestry Games has licensed HTML5 and Android games since 2017 and develops HTML5 titles in-house, which is the distinction that matters for a project like this: what you can ship into a surface like Discord depends entirely on whether the arrangement gives you a build you are permitted and able to modify. A distribution licence and a source-code arrangement are different products at different prices, and the second one is the one that survives contact with an SDK integration. If you are scoping a channel that needs code-level changes, ask about source access up front rather than discovering the gap after you have picked titles from the catalogue.
✅ The Next Thing to Do
Before you write a line of integration code, run the cheap test. Take the single best multiplayer candidate in your catalogue, open it in a browser with the network tab recording, and list every external host it contacts. Then check your licence agreement for two clauses: whether you may modify the build, and whether you may remove the licensor's outbound links and branding.
Those two checks take an afternoon and they settle the question. If the answers are no, Discord is not a channel you have — it is a channel you would have to buy differently to reach, and that is a procurement decision rather than an engineering one. If the answers are yes, you have a genuine shot at 200 million people who are already in a voice channel looking for something to do together, which is a better starting position than almost any portal deal on the table.
