The actual size limit

Mintegral's cap is 5 MB for the packaged creative. That number applies to the final ZIP as submitted — not the raw Unity Playworks/Luna export, and not the source assets before encoding. Mintegral accepts a ZIP archive with resources inside it (allowsZipResources), so unlike AppLovin or Meta it doesn't force everything into a single inlined HTML file — but the ZIP as a whole, entry file included, still has to clear 5 MB.

That distinction matters because it's the source of most size surprises: a build that looks fine in the Unity editor can grow once textures, audio, and any embedded assets are packaged for submission, and the number that counts is the one Mintegral measures on the archive you actually upload.

1. Size overage

This is the most straightforward failure — the packaged ZIP simply comes in over 5 MB. It happens most often with Unity exports because the engine runtime, uncompressed textures, and per-clip audio files add up fast, and none of that is obvious from looking at the project in the editor. Because Mintegral allows resources inside the ZIP rather than requiring a single self-contained HTML file, there's more room to stay under the cap than on AppLovin or Meta — but "more room" isn't "no limit," and it's still a hard 5 MB ceiling on the final archive.

Fix: compress textures and audio before packaging, strip unused Unity engine assets, and measure the actual ZIP you're about to submit — not the raw export. PlayableKit's free size checker reports the real packaged size per network, including Mintegral's 5 MB cap, before you submit.

2. Archive, folder, and HTML name mismatch

Mintegral requires the ZIP archive name, the top-level folder inside it, and the HTML entry file name to all match each other (requiresMatchingZipFolderHtmlName). This is a purely structural check that has nothing to do with whether the game runs — it fails at intake, often before a reviewer ever opens the creative. It's also one of the easiest mistakes to make by accident: renaming a Luna export folder for a new campaign, or re-zipping an existing build under a different filename, breaks the match without anyone touching the HTML at all.

Fix: before zipping, confirm all three names line up exactly. See Mintegral name mismatch rejected for the full breakdown of how this mismatch happens and how to avoid it consistently across campaigns.

3. Missing or wrong click API

Mintegral's click-through is window.install(), with a fallback to mraid.open(url) — not interchangeable with the MRAID-only call other networks expect, and not the same as Google's ExitApi.exit() or Meta's FbPlayableAd.onCTAClick(). A CTA button that renders and looks clickable but never actually calls window.install() (or the MRAID fallback) passes a casual local test and still fails Mintegral's review, because the review process specifically checks for that call firing, not just that a button exists.

Fix: confirm every CTA path — including any end-card or replay-then-install flow — invokes window.install() with the MRAID fallback wired in correctly. For the full explanation of why this specific API and fallback pattern trips builds up, see Mintegral game-end callback missing and the related click-API breakdown it covers.

4. Missing gameEnd() callback

Mintegral also requires a working window.gameEnd() callback, separate from the click-through API. Mintegral's own testing explicitly confirms both the game-end and app-store click callbacks fire — a playable that never calls window.gameEnd() can otherwise look complete (the game plays, the CTA button works) and still fail review because that specific signal never arrives. This is easy to miss because nothing about it is visible in a browser: the game doesn't error out, it just silently never reports that it ended.

Fix: make sure your build calls window.gameEnd() at the actual end-of-game moment, not just on the CTA click. See Mintegral game-end callback missing for exactly where this callback needs to fire and how to verify it before submission.

5. Other structural requirements

Beyond the four categories above, Mintegral's spec is comparatively lenient on structure — it doesn't force a single-file build like AppLovin or Meta, and it doesn't require a companion config file the way TikTok does. The requirements that do apply are the ones already covered: the entry file itself has to be present and correctly referenced inside the matched archive/folder structure, and both callbacks (click and game-end) have to actually fire, not just exist somewhere in the code. If a Playworks/Luna export runs correctly in a browser but hasn't been adapted for Mintegral specifically, the gap is almost always one of these — not a hidden sixth rule.

Worth knowing: size, packaging shape, and both callbacks are all things Mintegral's intake checks mechanically before any human reviews the creative. None of them relate to how good the game itself is — they're the same for a weak prototype and a polished creative. For the complete requirements reference, see Mintegral Playable Ads: Requirements, Formats & Common Errors.

Catching these before you submit

Every category above is checkable on the package itself, before it reaches Mintegral's review: the final ZIP's byte size, whether the archive/folder/HTML names match, and whether window.install() and window.gameEnd() are actually wired to fire rather than just present in the code. PlayableKit's free Playable Ad Validator checks structure and callback wiring against Mintegral's actual spec, and the free size checker reports the real post-packaging size against the 5 MB cap — both with no signup, before you spend a review cycle finding out the hard way.

If you're adapting a Unity Playworks/Luna export by hand for Mintegral specifically, PlayableKit automates the archive/folder/HTML name matching, the window.install()/MRAID fallback wiring, and the window.gameEnd() callback directly from your source build, then checks the packaged result against the 5 MB limit before you submit. See pricing for what's included on each plan.