What are Pangle's playable ad packaging requirements?

Pangle is unusually strict about packaging: a ZIP with the HTML entry point correctly named and placed, and absolutely no runtime requests. The packaging effectively is the spec — creatives that would pass elsewhere fail on structure alone.

Why does Pangle enforce the no-request rule so strictly?

Pangle serves into publisher apps where an outbound request from a creative is both a latency risk and a policy exposure. Because it is checked automatically at upload rather than during human review, a single external font or analytics beacon fails the submission outright.

How do Pangle and Liftoff differ?

They share a ZIP-based submission and a no-external-requests rule, but the store exit differs: Pangle uses window.openAppStore(), matching TikTok, while Liftoff calls Liftoff.open() once MRAID reports the ad ready and on screen. Liftoff also buys programmatically with ML-driven bidding, so it rewards creative variety more than Pangle does.

How do you diagnose a rejection on Pangle or Liftoff?

Work in this order: confirm the ZIP structure and entry-point name, confirm no asset reaches an external host, confirm the file size, then confirm the store exit matches that network's API. The first two account for most rejections and are both visible by inspecting the file before upload.

Pangle & Liftoff Playable Ads: Packaging & Submission

Pangle and Liftoff both carry real playable volume, and general guides that stop at Google, Meta and Unity barely cover them. They share one trap: rejections are almost never about the creative and almost always about how the archive is put together. This guide covers the packaging rules that decide acceptance. Current specs: Pangle and Liftoff playable ad specs.

Pangle: the packaging is the spec

Pangle is now the TikTok Ad Network, bought through TikTok Ads Manager, where playables run in Smart+ App Promotion campaigns and TikTok generates the end card. Its playable requirements are specific and easy to get slightly wrong.

Submit a .zip, not a loose HTML file.
The main HTML file must sit in the first-level directory and must be named index.html. Not main.html, not ad.html, and not one folder deep.
The package is expected to include config.json alongside index.html, with its playable_orientation (0 responsive, 1 portrait, 2 landscape).
Compressed size under 5 MB.
No JS redirects anywhere in the creative.
No HTTP requests at runtime: everything embedded.
The click-to-jump operation is handled through the network's own front-end SDK (include TikTok's playable JS SDK and call window.openAppStore()) rather than a raw browser call.

The first-level directory rule

This is the single most common Pangle rejection. On most operating systems, right-clicking a folder and choosing Compress produces an archive containing that folder, so index.html ends up one level down. Select the files themselves and compress those. Then extract the archive fresh into an empty directory: if the first thing you see is a folder rather than index.html, it will be rejected.

Why the no-request rule is enforced so strictly

The prohibition on HTTP requests and JS redirects is not bureaucratic. A creative that fetches at runtime can change after review, which makes the review meaningless, and it introduces latency into a format measured in seconds. Networks in the ByteDance family enforce this aggressively, and automated checks catch it reliably, including requests you did not intend, such as a font that was linked rather than embedded, or an analytics call left in from a test build.

Liftoff

Liftoff is a programmatic DSP with machine-learning-driven optimisation, and it now includes Vungle following their combination, which matters practically, because Vungle's playable requirements are the ones you are likely to encounter under the Liftoff name.

Liftoff's own click handling does not take a URL from your creative in the way a plain MRAID network does: the creative calls Liftoff.open() or mraid.open() with no URL and Liftoff supplies the destination, so a per-button custom destination cannot travel there. If your creative relies on sending different users to different destinations, that is a network-level constraint rather than something to solve in the creative.

ZIP packaging, with the entry file at the archive root: the same trap as Pangle.
MRAID for timing: check its state, wait until it is ready and on screen, then exit with Liftoff.open().
Up to 5 MB, no iframes, and no close button of your own: Liftoff adds one, so keep the top corners clear.
Fully self-contained; no runtime fetching.
Because Liftoff optimises on machine learning, creative variety matters more than on a manually-bid network. A single creative gives the model very little to work with.

What ML-driven buying means for your creative plan

This is the strategic difference between these networks and a manually-managed one. On a DSP that optimises with machine learning, the model is looking for signal about which users respond to which creative. Give it one playable and it has almost nothing to choose between.

In practice that means shipping a small set of clearly different creatives rather than one polished creative and a set of near-identical colour variants. Different mechanic, different opening, different end card framing. Variants that differ only cosmetically look like one creative to the model.

A shared submission checklist

Build to the strictest size ceiling among your target networks, not the most generous.
Extract every archive fresh into an empty folder and confirm the entry file is at the root, correctly named.
Include any per-network manifest the network expects alongside the entry file.
Record the browser network tab through a complete playthrough: zero external requests.
Grep the built file for redirect patterns and stray script tags left from development.
Test on real iOS and Android devices, not emulators.
Submit to the strictest network first; passing there predicts the rest.

Where the real cost sits

None of these rules are difficult individually. The cost is that they differ per network, and they must be reapplied to every revision of every creative, which is where mistakes enter. If the export produces the right packaging, entry-file name and click handling for each network, the checklist becomes part of the build instead of a manual chore.

Fitting them into a network mix

Pangle pairs naturally with TikTok, since they share an ecosystem and often an audience strategy. Liftoff sits alongside Moloco as the programmatic, ML-optimised half of a buying mix, contrasted with the mediation-heavy Unity and AppLovin side. Running one creative across all of them is reasonable, provided it was built to the tightest constraint in the set and packaged correctly for each.

Diagnosing a rejection on either network

Rejection notices from both are terse, and the wording rarely names the real cause. A diagnostic order that saves time:

Extract the submitted archive into an empty folder. If index.html is not the first thing you see, correctly named, stop: that is almost certainly it.
Check for a missing manifest file where the network expects one alongside the entry file.
Search the built HTML for http:// and https:// outside of comments. Anything not embedded is a request, including a linked font or a leftover analytics endpoint.
Search for redirect patterns (location assignment, meta refresh, window.open) which are prohibited outright rather than merely discouraged.
Check the compressed size against the ceiling, not the uncompressed size.
Only then look at the creative itself.

The ordering matters because the first three causes account for the large majority of rejections on these two networks, and each takes under a minute to check. Teams frequently rebuild a creative in response to a rejection that was actually an archive structure problem.

What to keep in your own notes

Published specs and what review actually enforces are not always in step, and both move. A short internal record (what each network accepted, what it rejected and with what wording, and the date) becomes more reliable than any external documentation within a couple of campaigns. It is also the fastest way to onboard whoever inherits the account.

Test the archive, not the folder

The most useful habit for these two networks: never submit an archive you have not extracted fresh into an empty directory and inspected. It catches the packaging class of failure entirely, and packaging is where these networks reject most creatives.

Create playable end cards in minutes—no code required.

Open Playable Ads Maker

Check a build against these specs

The free Playable Ad Spec Checker grades an HTML or ZIP against every network’s size cap, packaging, MRAID rules and store-exit calls. It runs entirely in your browser — no upload, no sign-up.