Why this is worth five minutes
A rejected creative isn't just a "try again." Most networks put it back through a manual or automated review queue, which costs you the review cycle time all over again — often a day or more before you find out. Several networks also track rejection rates per account and throttle how quickly they'll re-review submissions from accounts that keep sending broken creatives, turning one sloppy export into a slower pipeline for every creative after it.
Almost none of the common rejection reasons — a missing click-through, an asset that didn't load, a build that's 30% over the size cap — require a network's review team to catch them. They're all visible before you submit, if you check for them.
The pre-submission checklist
1. Open the raw export locally first
Before anything else, unzip the Playworks/Luna export and open index.html directly in a browser (or serve the folder locally). This catches the most basic failure mode: an asset that didn't get bundled, a relative path that broke, or a scene that never finishes loading. If it doesn't run cleanly here, it's not going to run cleanly anywhere downstream, and there's no point wiring it up for a network yet.
2. Run the free Validator for structural problems
Next, run the export through PlayableKit's free Playable Ad Validator — no signup, no conversion. It checks that index.html actually exists at the archive root, that the engine or Luna cache assets it depends on (engine/scripts.js, or a full cache/<id>/{scripts,jsons,blobs}.js set) are all present, that there's a recognizable click-through pattern in the code, that every inline <script> block parses without a JavaScript syntax error, and it reports the overall file count and uncompressed size. This is the fastest way to catch a broken export before you've spent time on anything network-specific.
3. Run the free Size Checker against real per-network caps
Raw export size doesn't tell you much — the converted, network-ready file is often smaller once unused cache generations get dropped, or larger once every asset gets inlined as base64/base122 for a network that requires it. The free Size Checker actually runs your export through the same conversion pipeline used for paid builds, for every supported network, and reports the real resulting byte size against each network's actual cap — not an estimate from your upload size.
4. Manually trigger the click-through
A validator can tell you a click-through pattern exists in the code; it can't tell you it actually fires when a real player taps it. Click or tap the playable's CTA yourself and confirm the install/store intent launches. Each network expects a different call — Google's clickTag/ExitApi, AppLovin's and Unity Ads' mraid.open(), Vungle's postMessage('download'), Mintegral's window.install(), TikTok's openAppStore(), Meta's FbPlayableAd.onCTAClick() — and a wrong or missing one is one of the most common reasons a creative gets rejected outright.
5. Test both orientations, if the network requires it
Several networks either require or strongly prefer creatives that work in both portrait and landscape. If your target network is one of them, rotate the device (or the browser viewport) and confirm the layout, hit areas, and CTA still work in both — a playable that was only ever tested in one orientation is a common source of a "layout broken" rejection that never shows up in a validator report.
What PlayableKit's conversion handles automatically vs. what still needs manual testing
| Task | Handled automatically | Still needs manual testing |
|---|---|---|
| Click-through API wiring | Correct clickTag/MRAID/SDK call applied per network | Confirming it actually fires on tap in a real player |
| Asset embedding | Base64/base122 encoding for networks that require it | Visually confirming nothing renders broken post-encoding |
| Package shape | Filenames, folder structure, config.json generated to spec | — |
| Size vs. cap | Real converted size measured per network | Deciding whether to trim assets if a network still fails |
| Orientation support | Not enforced — depends on how the scene was built | Rotating and testing both orientations yourself |
| Gameplay/asset integrity | Not checked at conversion time | Opening the raw export locally first (step 1) |
The pattern is consistent: conversion removes the mechanical, rule-based parts of compliance — the exact API call, encoding, file layout. It can't tell you whether the game plays right or whether a human would find the CTA — that's still on you, and it's exactly what steps 1, 4, and 5 are for.
If your export has a deeper problem than size or wiring — assets that silently didn't make it into the build at all — that's a different failure mode worth checking separately; see what to do about missing assets in a Playworks/Luna export.