We Tested a Playable Puzzle Inside an X Player Card
Can a puzzle run inside an X post rather than sending someone to another website?
In our test, yes. We published a small, free Bounty Puzzle sliding game using Player Card metadata. A real mobile X session displayed the interactive board inside the post. The player completed the puzzle, saw the restored logo and had a working Restart control.
That is a useful technical result. It is not evidence that X has approved our use case, that games are a supported Player Card category, or that the experience works in every X client.
This article explains the experiment, the implementation decisions that mattered, and the restrictions developers should understand before treating Player Cards as an application platform.
What we actually have working
The published trial is deliberately small: a 3×3 sliding puzzle that reconstructs the Bounty Puzzle logo.
Players move a tile next to the empty space, using touch or mouse controls. Keyboard arrows move the gap. The player counts moves, detects completion, restores the final logo piece and supports restarting.
On 14 October 2026, the owner confirmed successful inline play in a real X post. Their mobile screenshot showed the completed puzzle at 70 moves, with Restart available.
This was more than a thumbnail opening our website: the completed interactive player was visible within the post.
The public trial does not include:
- X sign-in or identity verification.
- A leaderboard or server-verified competitive scores.
- Payments, cash prizes, coupons or virtual currency.
- Media rewards or exclusive-content access.
- Email capture or automatic posting to X.
The game state stays in the browser. Its move counter is suitable for this no-reward demonstration, not for awarding prizes or publishing trusted rankings.
You can inspect the experiment's public share page or open the player directly.
The mechanism: a share page and a separate player
Player Cards use metadata on a public webpage to identify a separate player URL. The metadata names still use the twitter: prefix, despite the platform now being called X.
Our implementation separates three things:
- The share page: complete HTML containing the Card metadata.
- The player page: the compact, self-contained puzzle.
- Public assets: the logo, JavaScript module and preview image.
The share page emits its metadata on the server. X does not need to execute our main application's JavaScript to discover it.
A simplified version of our metadata looks like this:
<meta name="twitter:card" content="player">
<meta name="twitter:title"
content="Bounty Puzzle — X Player Card experiment">
<meta name="twitter:description"
content="A free, no-reward sliding puzzle experiment.">
<meta name="twitter:image"
content="https://bpuzzle.app/x-puzzle/assets/preview.jpg">
<meta name="twitter:player"
content="https://bpuzzle.app/x-puzzle/player">
<meta name="twitter:player:width" content="480">
<meta name="twitter:player:height" content="480">
These tags request a rendering mode. They do not force X to display a player, grant approval or turn an unsupported use case into a permitted one.
We used the verified production domain for absolute metadata URLs. We did not construct them from an arbitrary incoming Host header or point them at a development preview.
The implementation details that mattered
Public, signed-out access
The crawler needs to reach the share page, player and assets without a login screen.
We kept the demo routes separate from our authenticated dashboard and registered them before the site's authentication middleware. The trial does not need a Bounty Puzzle session cookie to load or play.
Missing assets return a real error rather than the main application's HTML fallback. This matters: a JavaScript URL returning an HTML page with a successful status can look reachable while still failing in the browser.
Scoped iframe permissions
Embedding is a browser security decision as well as a platform decision.
Our player response uses a Content Security Policy with explicit framing permissions for the trial. We did not weaken the framing protection on the dashboard, account pages or payment flows.
The local share page also previews the player in a sandboxed iframe. Public demo assets have the cross-origin access needed for that sandboxed preview; private APIs and credentials do not.
A successful iframe on your own site proves that your page can be framed there. It does not prove that X will accept the Card or use the same sandbox configuration.
A compact player, not a dashboard in miniature
Our metadata requests a 480×480 player. The layout was also checked at smaller square sizes, including 350×350 and 250×250.
The game uses one image sliced across numbered tiles. Controls, move count and completion feedback fit the player rather than relying on a full application shell.
We checked touch, keyboard input, legal moves, completion and restarting. We also checked visible errors when required assets fail to load.
A fallback and an off switch
The same experiment has an ordinary large-image Card variant, with direct play on our website.
We also built an off switch that changes the share page to an image Card and removes X framing permission from the player after rebuilding and republishing.
This gives us a way to withdraw the experiment. It cannot erase X's cached previews, and a fallback must not be used to circumvent a rejected use case.
What X's current Card policy restricts
We reviewed the official X Developer Policy's Cards section on 14 October 2026.
Two statements are particularly important:
“You may not exceed or circumvent X’s limitations placed on any Cards, including the Card’s intended use.”
“You may not attach monetary incentives (including virtual currency) within your Card or on X from your Card.”
The policy also requires or restricts the following:
| Area | Published requirement | What it means for this experiment |
|---|---|---|
| Platform coverage | Develop Cards to render across all platforms where Cards are displayed. | One successful mobile session is not enough to claim broad client support. |
| Transport security | Host all Card assets over HTTPS; avoid active mixed content. | The player, scripts and images must all use secure URLs. |
| Sensitive media | Mark the post appropriately if sensitive media will appear within the Card. | The label does not override other X content rules. |
| Audio and video | Provide stop or pause controls; automatically playing videos should default to sound off. | Any future video experience would need its own playback review. |
| Sponsorship | Third-party sponsored content requires X approval. | A sponsor-funded activation cannot be assumed permissible just because the iframe renders. |
| Context | Content and actions must not be misleading or contextually irrelevant. | A reveal or outbound destination should match what the post promises. |
Removing payments does not establish permission to run a game in a Player Card. Nor should developers assume that moving a monetary incentive behind an external link avoids the wording about incentives “on X from your Card.”
Our no-reward trial avoids adding those monetary incentives. The separate intended-use question remains unresolved.
Games have a relevant policy history
Player Cards have historically been described as players for video and audio, rather than general-purpose interactive applications.
In 2015, The Guardian reported that Twitter disabled playable MS-DOS games embedded in posts. The report quoted then-current Player Card guidelines excluding end-to-end experiences involving purchasing, gaming, polling, messaging and data entry.
That is historical reporting, not a claim that we have verified identical wording in today's detailed Player Card guidelines.
We tried to retrieve the official Player Card documentation, but it returned HTTP 403 during our review. We therefore cannot use that page to claim either that the old restriction remains unchanged or that X has removed it.
The current broader rule against circumventing a Card's intended use is still published. A developer considering a non-standard interactive player should obtain clarification and any required approval from X before offering it as a dependable customer channel.
We would not disguise the puzzle as a video or treat successful rendering as a workaround for policy.
What we have not established
This experiment proves a narrow result: our free puzzle was playable inside the owner's observed mobile X session.
It does not establish:
- Consistent behaviour across desktop, iOS and Android clients.
- Permanent eligibility or approval for puzzle-based Player Cards.
- Reliable sign-in, cookies or account linking inside the frame.
- Permission or compatibility for media rewards.
- Support for cash rewards, checkout or other monetary incentives.
- That an outbound button opens reliably from inside the X player.
We considered post-solve X authentication and leaderboards, but did not ship them. A browser-reported move count would not be a trustworthy competitive score; server validation and an account-claim flow would add further work.
Media-link reveals are another possibility under evaluation, not a working feature of the published trial.
For example, we opened one public Grok Imagine image share link without signing in. That confirms public viewing for that example. It does not prove that the Grok page can be embedded inside our puzzle: its framing policy did not permit Bounty Puzzle as a parent.
A button that opens Grok separately after completion may be a simpler approach, but that button still needs a real X-post test.
A practical checklist for developers
Before offering a Player Card integration to customers:
- Check policy first. Identify the intended Card use and obtain clarification or approval for a non-standard experience.
- Serve metadata in the initial HTML. Do not depend on a crawler running your main frontend application.
- Use public HTTPS routes and assets. Test signed out, including missing-asset responses.
- Keep framing permissions narrow. Do not make the rest of your application embeddable just to support a demo.
- Test the actual post. Record whether the experience stays inline, opens a browser or falls back to an image.
- Test client coverage. Distinguish your own browser tests from observed results in real X clients.
- Separate basic rendering from advanced flows. Authentication, external links, media playback and rewards each need additional validation.
- Provide a direct-play fallback and withdrawal mechanism. Neither is an excuse to evade a platform rejection.
Frequently asked questions
Does the working puzzle mean X officially supports games in Player Cards?
No. It demonstrates technical rendering in our observed session, not platform approval or a supported game category.
Did this trial need X OAuth to play?
No. The published demonstration does not authenticate X accounts or call the X API to run the puzzle. Account-linked scores would be a different integration, with different requirements.
Can developers add monetary puzzle rewards?
Do not assume so. X's current Card policy explicitly prohibits attaching monetary incentives, including virtual currency, within the Card or on X from it.
The takeaway
We have a playable, no-reward puzzle that worked inside a real X post. That makes Player Cards technically interesting to investigate.
We do not have an approved, universally supported puzzle-sharing channel.
For developers, the useful lesson is to separate what the browser rendered, what real users tested, and what the platform permits. Each needs its own evidence before an experiment becomes a product.
Sources and further reading
- X Developer Policy — X Cards: current Card restrictions reviewed for this draft.
- Official Player Card documentation: returned HTTP 403 during our review; not used to assert current detailed approval criteria.
- The Guardian: Twitter kills MS-DOS games embedded in tweets: historical reporting from 4 May 2015.
- xAI Consumer FAQ: public conversation sharing and revocation; not a blanket guarantee about Imagine media or embedding.
- Bounty Puzzle's live trial: the public experimental share page.
Build something people want to play.
Explore a working example, review the integration docs, or start your first campaign.
