Where this stands today: PlayableKit currently exports network-compliant packages for its supported networks from a single Playworks/Luna source build. InMobi is planned but not built — no launch date to share yet. If InMobi is one of your networks right now, the notes below reflect InMobi's actual documented spec, verified against InMobi's own support pages rather than guessed at.

What InMobi's creative spec actually requires

InMobi publishes its playable ad requirements in its DSP creative specifications and guidelines documentation. The core technical requirements, as documented there:

RequirementInMobi's documented spec
Maximum file size5 MB
Media formatHTML5 with JavaScript tags
DimensionsFullscreen, portrait and landscape; responsive design recommended
Submission formatEither a single index.html with all assets inlined as data URIs, or a zipped folder containing index.html plus assets in structured subfolders
MRAID complianceMRAID 3.0, with <script src="mraid.js"></script> in the HTML <head>
Click trackingFbPlayableAd.onCTAClick() or $HTML_ESC_CLICK_URL as placeholders
Redirect to storemraid.open(url)

Two details are worth calling out because they're easy to get wrong if you're used to other networks' conventions.

InMobi accepts either a single file or a ZIP

Unlike networks that mandate one packaging shape, InMobi's spec explicitly allows two submission formats for custom-coded playables: a single, fully self-contained index.html with every asset inlined as a data URI, or a zipped folder with index.html at the root alongside subfolders for supporting assets. Either is acceptable — the spec's only hard rule is that the HTML itself be minified and that nothing loads externally at runtime (no HTTP requests, no XMLHttpRequest calls, no dynamic asset loading or JS redirects to outside domains).

The click-tracking placeholder is a naming quirk, not a typo

InMobi's own documentation lists FbPlayableAd.onCTAClick() — an identifier that originated with Meta's playable ad SDK — as one of two accepted click-tracking placeholders, the other being $HTML_ESC_CLICK_URL. If you're adapting a build that was already wired for Meta, that's a point in your favor: the same CTA hook may already be present. For the redirect itself, InMobi expects the standard MRAID call, mraid.open(url), to hand off to the app store — and the spec is explicit that the redirect must be gated on user action, not fired automatically.

InMobi also documents a native Playworks/Luna ingestion path — separate from the custom-code path above

Worth knowing if you already have an active InMobi relationship: InMobi's documentation describes a direct submission route for advertisers exporting from a Unity account — log in, open the Creatives tab, choose InMobi as the ad network, download the playable, and share it with your InMobi point of contact. That path (along with similar integrations InMobi documents for Craftsman Plus and PlayTurbo) is distinct from the custom-coded HTML5 route above, and it's account-rep-driven rather than a self-serve upload dashboard. The spec above — file size, MRAID, click tracking — is what applies if you're taking a standalone Playworks/Luna export ZIP and hand-packaging it yourself rather than going through that account-linked flow.

None of this is inferred. Every figure and code snippet above was pulled directly from InMobi's published creative specifications and guidelines documentation at support.inmobi.com and cross-checked against the raw page content, not summarized secondhand. If InMobi updates its spec after this was written, treat InMobi's own page as the source of truth.

What this means if you're adapting a Playworks/Luna export today

If you're hand-porting a Playworks/Luna export ZIP to InMobi's custom-code path right now, the practical checklist looks like this:

  • Decide single-file or ZIP — both are accepted, so pick based on whichever is less rework: inlining every asset as a data URI for a single index.html, or keeping the export's folder structure and zipping it with index.html at the root.
  • Add MRAID 3.0 support — include the mraid.js script reference in <head>, and gate your playable's start on the mraid.viewableChange event rather than firing on load.
  • Wire the CTA correctly — implement FbPlayableAd.onCTAClick() or the $HTML_ESC_CLICK_URL placeholder, and route the actual redirect through mraid.open(url), never an automatic redirect.
  • Strip anything that reaches outside the file — no external HTTP calls, no dynamic script or asset loading. Everything the playable needs has to already be inside the package.
  • Keep it under 5 MB — check this before submission, not after a rejection. PlayableKit's free size checker will tell you exactly how big your build is and what's driving the weight.

What is automated today

PlayableKit's job — turning one Playworks/Luna export into network-compliant packages without touching HTML by hand — covers InMobi alongside every other supported network. Each gets its own clickTag/MRAID/SDK wiring, asset encoding, and package shape generated automatically from the same source build.

Two tools are also free regardless of which networks you're targeting:

  • The Playable Ad Validator checks a Playworks/Luna export for structural problems — missing entry files, broken inline scripts, missing engine assets — before you convert it for anything.
  • The size checker tells you exactly how large your build is and what's contributing to it, which is directly useful against InMobi's 5 MB ceiling.