index.html and config.json, fully self-contained. One honest caveat: Snap documents its own specific CTA callback, and PlayableKit couldn't independently confirm the exact current function name from Snap's Business Help Center, so the package ships with a generic fallback flagged in the build report — swap in Snap's documented callback before a real submission.
Snap's playable ad requirements
The specifics below are drawn from Snap's own developer and business documentation — primarily the Media reference on developers.snap.com and the "App Playables" article in Snap's Business Help Center. Ad network specs change without much notice, so treat this as a starting orientation, and confirm current details against Snap's own pages before you build a final creative around them.
- Package format: a ZIP file, not a single HTML document. Snap's documented structure is a ZIP archive containing an
index.htmlfile and aconfig.jsonfile, both at the first level of the archive — not nested inside a subfolder. This is a meaningfully different shape from AppLovin's or Meta's single self-contained.htmlfile requirement, so a package built for one of those networks can't just be renamed and reused for Snap. config.jsoncarries orientation metadata. Alongsideindex.html, the archive needs aconfig.jsondeclaring the playable's supported orientation (landscape/portrait). This is the same general idea as the config file Mintegral and TikTok each require, though the exact field names and accepted values are Snap's own — check Snap's current documentation for the specific schema before hand-building one.- 5 MB maximum file size. This limit is stated directly on Snap's Media reference page for creative uploads. As with every other network's size cap, it applies to the final packaged file — after any base64 encoding of assets — not to your uncompressed source files.
- Self-contained, no outbound network calls. Snap's documentation is consistent with the pattern seen across most rewarded and app-install playable formats: the creative should not depend on dynamically loading assets from an external server at runtime, and shouldn't fire outbound HTTP requests once served. Assets generally need to be packaged with the creative rather than fetched live.
- A documented click-through callback. Snap's Business Help Center documents a specific JavaScript callback that a playable's CTA element is expected to call on interaction, separate from a generic
window.open()or anchor-tag link. If you're hand-building a Snap creative, pull the exact current function name and calling convention directly from that "App Playables" article rather than assuming it matches another network's clickTag, MRAID, or SDK-callback pattern — Snap's is its own. - No JS redirects. Snap's documentation calls out that the playable shouldn't perform its own JavaScript-based page redirects — navigation away from the ad is expected to go through the documented click callback, not a generic redirect.
How this compares to the networks PlayableKit already supports
If you're used to building for AppLovin, Meta, or Vungle, Snap's ZIP-plus-config-file shape will feel unfamiliar; if you're used to Mintegral or TikTok, it will feel closer to home:
| Network | Package shape | Click-through |
|---|---|---|
| AppLovin / Meta / Vungle | Single self-contained .html file | MRAID / postMessage / SDK call, no separate config file |
| Mintegral / TikTok | ZIP with matching folder/file naming, plus a config file | Network-specific JS function (window.install(), openAppStore()) |
| Snap | ZIP with first-level index.html + config.json | Snap-documented JS callback, called on CTA interaction |
The overlap that matters most in practice: the 5 MB ceiling and the "no live external requests" rule show up in almost every network's spec, Snap's included. Assets fully embedded, click-through wired to the exact call the network expects, and a package shape that matches what that network's upload pipeline scans for — that's the same underlying discipline PlayableKit automates for every network it supports.
How PlayableKit builds for Snap
PlayableKit's converter matches Snap's package shape directly: a ZIP with a first-level index.html and config.json, fully self-contained with no outbound calls. The one piece PlayableKit doesn't guess at is the exact CTA callback name — Snap's Business Help Center documents one, but PlayableKit couldn't independently confirm the current exact function name, so the build wires a generic fallback and the build report flags it explicitly, rather than shipping a guessed name that could fail silently in review.
- Run your raw export through the free validator. The Playable Ad Validator checks a Playworks/Luna ZIP for structural issues — missing entry files, broken inline scripts, missing engine assets — before you convert it for any network.
- Check real post-encoding file size. The free size checker shows what your build actually weighs once assets are embedded, so you're working against Snap's 5 MB limit with a real number instead of a guess.
- Confirm Snap's exact CTA callback against Snap's own current documentation before a real submission, and swap it into the generated package in place of the generic fallback.