What Mintegral is and why playables matter there

Mintegral runs playable ad units as part of its standard interactive inventory across mobile apps and games. Like most performance-focused networks, it treats a working playable demo as a higher-intent creative than a static image or video — a user who plays a few seconds of your game before tapping install is a better signal than a passive impression. That's also why review checks functional behavior, not just file structure: a playable that looks fine but doesn't fire its callbacks correctly is treated as broken. Mintegral is also stricter about container shape than most networks that accept a plain ZIP — where Google Ads mostly cares about what's inside the archive, Mintegral cares, very specifically, about what the archive, the folder, and the file are each named.

Technical requirements

Mintegral's playable spec breaks down into a small number of hard requirements. Every one of these is checked during review, not just recommended:

  • Package format — a ZIP archive. Mintegral does not accept a single self-contained HTML file the way AppLovin or Meta do; the interactive creative has to be zipped.
  • Size limit — 5 MB or smaller for the entire package, assets included. This is a hard cap enforced at upload, not a soft guideline.
  • Entry file path — the HTML entry point must sit at exactly mintegral/mintegral.html inside the archive. Not at the ZIP root, not under a differently named folder, not under a nested subdirectory — that exact relative path.
  • Matching archive/folder/file names — the ZIP's filename, the top-level folder inside it, and the HTML file inside that folder all have to share the same base name. This is Mintegral's most distinctive rule and the one most other networks don't enforce.
  • Click-through CTA — the primary call to action must invoke window.install(). If that function isn't available in the render context, the CTA needs to fall back to mraid.open(url) so the click still resolves to an app-store redirect.
  • Game-end callback — the playable must call window.gameEnd() at the point where its interactive portion is complete (typically the end-card or "install now" screen). Mintegral's own QA explicitly tests that this callback and the click callback both fire, so a playable that runs fine visually but never calls gameEnd() still fails review.

Individually none of these are exotic, but combining a strict entry-path rule with a strict naming-match rule is unusual — most networks enforce one or the other, Mintegral enforces both.

Accepted formats and size limits

Mintegral accepts a ZIP archive containing HTML5/JavaScript assets — images, audio, and any engine runtime code your build depends on. Assets can ship as ordinary separate files inside the archive rather than being inlined as base64, which is a meaningful difference from networks like AppLovin that demand a single flattened HTML file: a Unity-exported playable with several image and audio assets can keep those as normal files inside the ZIP, referenced by relative path from mintegral/mintegral.html.

The size cap is 5 MB for the complete package — HTML, JavaScript, images, audio, and any bundled runtime combined, with no separate per-asset limit. Sprite sheets and a short audio loop usually sit comfortably under that limit, but multiple full-resolution backgrounds, longer voiceover clips, or an uncompressed video end card can push a build over quickly. Compressing textures, trimming audio bitrate, and stripping unused engine code are the usual fixes when a build is running close to the ceiling.

Common upload errors

Mismatched archive, folder, and HTML file names

This is the error that catches the most teams, and it's dangerous because it's invisible during testing — a naming mismatch doesn't break anything a QA pass would catch. The playable opens, plays, and ends correctly in a browser; it only surfaces during Mintegral's own review, after submission.

Concretely: say your ZIP is named build.zip, containing a folder named creative, containing a file named index.html. Every functional requirement can be satisfied — window.install() works, window.gameEnd() fires correctly, the package is under 5 MB — and Mintegral still rejects it, because build, creative, and index don't match each other and the entry isn't at mintegral/mintegral.html. All three names need to agree instead: a ZIP named mintegral.zip, a top-level folder named mintegral, a file named mintegral.html. This is easy to break later, too — a re-zip using an OS's default "Compressed folder" name, a leftover folder from an earlier test build, or a rename applied to the ZIP but not the folder inside it are all common ways a previously-correct package drifts out of sync.

Missing or misplaced game-end callback

The second most common failure is a playable that never calls window.gameEnd(), or calls it only on a branch not every user reaches (like "replay") rather than unconditionally when the interactive portion ends. Since review explicitly tests for this callback firing, an otherwise complete playable can still fail because its end state never signals completion to the host SDK.

Click CTA with no MRAID fallback

Wiring the CTA to window.install() alone works inside Mintegral's own SDK context, but if the build is ever rendered in a generic MRAID container without that function present, a click with no mraid.open(url) fallback simply does nothing.

Entry file at the wrong path

Placing the HTML at the ZIP root, or under a folder that doesn't match the archive name, is effectively the naming-mismatch failure again: Mintegral looks specifically for mintegral/mintegral.html, so a file at just index.html without the enclosing folder won't be found.

Best practices

  • Build the archive name, folder name, and HTML filename together as one step rather than separate renames at different pipeline stages — that's the biggest source of drift.
  • Test the game-end and install callbacks on the actual end card, and confirm they fire even if the user skips or fast-forwards through the interactive sequence.
  • Keep the MRAID fallback in the click handler even though Mintegral's own SDK normally provides window.install() — it prevents a silent dead click in any other render context.
  • Recheck the packaged size after any asset swap — a single higher-resolution background or longer audio clip added late is a common way a previously-compliant build creeps over 5 MB.
  • Validate ZIP structure before uploading, not after a rejection — the naming-mismatch failure gives no feedback in a browser preview, so a structural check beforehand is the only way to catch it early.
Coming from Unity Playworks/Luna? If your source build is a Playworks/Luna export and you want the step-by-step workflow for turning that specific export into a Mintegral-ready package, see Export Unity Playworks/Luna to Mintegral — it walks through the naming rule and callback wiring in more detail, using that export as the starting point.

Export using PlayableKit

PlayableKit builds the Mintegral package for you rather than leaving the naming rule to manual attention: it names the output archive, top-level folder, and HTML entry file identically, places the entry at mintegral/mintegral.html, wires the CTA to window.install() with an mraid.open(url) fallback, adds the window.gameEnd() call at the correct point, and keeps the package under the 5 MB cap — flagging it before export if assets push the build over. The same upload also produces compliant packages for Google Ads, Meta, AppLovin, TikTok, Unity Ads, and Vungle in one pass. Mintegral is available on PlayableKit's Studio plan and above — see pricing for plan details and network coverage.

Before you submit: run any Mintegral ZIP — whether PlayableKit built it or it was packaged by hand — through PlayableKit's free playable ad validator to catch structural issues like the naming mismatch, and the size checker to confirm it's under the 5 MB cap before it becomes a rejection instead of a fix.