Mintegral Playable Ad Rejected for Name Mismatch: How to Fix It

The rule Mintegral is actually enforcing

Mintegral requires three names inside a playable submission to be identical: the ZIP archive's filename, the top-level folder inside that archive, and the HTML file inside that folder. Concretely, a package named mintegral.zip needs to contain a folder named mintegral, and that folder needs to contain a file named mintegral.html — giving an entry path of mintegral/mintegral.html. Change any one of the three and the other two no longer agree, and Mintegral's review flags the package as malformed. No functional test catches this because it isn't a functional problem — the HTML renders and runs exactly the same whether it's named mintegral.html or index.html. It only matters to Mintegral's own packaging check, which runs after the creative already works.

Why this trips people up

Almost nobody sets out to break this rule — it breaks by drift. The three names start out matching right after a build tool generates them, and then one of them changes later while the others don't:

• You download mintegral.zip, rename the local file to something more memorable for your own folder organization — say creative_v3.zip — and upload that renamed file without touching what's inside it.
• Your OS's built-in "compress to ZIP" action wraps a folder and names the archive after the folder, but the folder itself was left over from an earlier test build with a generic name like build or New folder.
• A teammate re-exports the same creative from a build pipeline that defaults its HTML entry file to index.html, without renaming it to match the folder and archive that were set up for an earlier Mintegral submission.

Any one of these leaves a package that's functionally complete and cosmetically fine to open in a browser, but structurally wrong in a way you won't see until Mintegral's review comes back.

Mismatch versus a correct package

Here's the same creative packaged two ways — one gets rejected, one doesn't:

Nothing about the HTML, the assets, or the game logic changed between the two rows — only the three names. That's the entire failure mode: three strings that need to be the same word, checked by a machine before a human ever looks at how the creative plays.

How to fix it

There are two ways to resolve this, depending on whether you're fixing a package by hand or building it going forward:

• Rename consistently, in one pass. Pick a base name, then rename the archive, the top-level folder inside it, and the HTML file inside that folder together as a single step — not as three separate renames done at different points in your workflow. That's where drift creeps back in even after a fix.
• Let the packaging step handle it automatically. If you're converting from a Unity Playworks/Luna export with PlayableKit, this is exactly what the Mintegral output target does: it nests the HTML one directory deep and names the archive, the folder, and the file identically every time a package is generated, so there's no manual rename step to forget or get half-right.

Either way, verify the fix before you resubmit rather than after another rejection — open the ZIP and confirm the archive name, the folder name, and the HTML filename all read the same word.