What Mintegral actually requires
Mintegral's playable spec is short, but every line in it is a hard requirement rather than a recommendation:
- Output format — a ZIP archive, not a single HTML file like AppLovin or Meta expect.
- Size limit — 5 MB or smaller for the whole package.
- Entry file path — the HTML entry point must live at
mintegral/mintegral.htmlinside the archive, not at the root and not under any other folder name. - Matching names — the ZIP's own filename, the top-level folder inside it, and the HTML file inside that folder all have to match each other.
- Click-through — the CTA must call
window.install(). If that's unavailable, it needs to fall back tomraid.open(url). - Game-end callback — the playable must call
window.gameEnd()when the interactive portion finishes, and Mintegral's own review explicitly tests that both this and the click callback fire correctly.
None of these are unusual asks individually — plenty of networks want a ZIP, a specific entry file, and an install-style click API. What trips people up is that Mintegral is unusually strict about the container itself, not just what's inside it.
The matching-name rule, in detail
This is the one worth slowing down on, because it fails silently in a way the others don't. A broken click handler or a missing asset shows up the moment someone tests the playable. A naming mismatch doesn't show up in testing at all — the creative runs perfectly in a browser, passes every functional check, and still gets rejected by Mintegral's review purely because the packaging didn't follow the convention.
Concretely: if your ZIP is called build.zip, and inside it there's a folder called creative, and inside that folder is a file called playable.html — that fails, even if the HTML runs flawlessly, even if window.install() and window.gameEnd() both work exactly as specified. Nothing about the ad itself is wrong. The archive name, folder name, and HTML filename simply don't agree with each other, and that alone is enough for Mintegral to bounce it.
The correct shape looks like this instead — every level of the name matching the entry path Mintegral expects:
| Layer | Wrong (rejected) | Right (matches) |
|---|---|---|
| ZIP filename | build.zip | mintegral.zip |
| Top-level folder | creative/ | mintegral/ |
| HTML entry file | playable.html | mintegral.html |
That's easy to state in a table and surprisingly easy to get wrong in practice, especially once a build has gone through a few rounds of renaming, re-zipping, or being handed off between a Unity dev and whoever's uploading to the ad network dashboard. A single re-zip with the OS's default "Compressed folder" name, or a folder left over from an earlier test build, is enough to break the match.
How PlayableKit builds this automatically
You still build the playable in Unity Playworks/Luna exactly as you do today and export the usual ZIP. From there, PlayableKit takes over the Mintegral-specific packaging:
- Names the output archive, the top-level folder, and the HTML entry file identically, satisfying the matching-name rule by construction rather than by manual attention — there's no step where a rename can drift out of sync.
- Places the entry file at the exact required path,
mintegral/mintegral.html, inside that matched folder. - Wires the CTA to call
window.install(), with anmraid.open(url)fallback wired in automatically for click-through. - Adds the
window.gameEnd()call at the point where the interactive portion of the playable finishes, matching what Mintegral's review tests for. - Keeps the whole package under the 5 MB cap, flagging it before export if the source assets push the build over.
Because the naming is generated rather than typed by hand each time, the failure mode above — a correct playable rejected for a container mismatch — isn't something that can happen with a PlayableKit-built Mintegral package. The same source Playworks/Luna export can also be packaged for Google Ads, Meta, AppLovin, TikTok, Unity Ads, and Vungle in the same pass, each with its own entry file, click API, and structural rules applied correctly.
Checking a build before you submit it
If you already have a Mintegral ZIP — whether PlayableKit built it or it was packaged by hand — it's worth confirming the naming and size before uploading it to Mintegral's dashboard. PlayableKit's free playable ad validator checks structural issues like this with no signup, and the size checker flags anything pushing toward the 5 MB limit before it becomes a rejection.