mraid.open() call as a reasonable inference rather than a quoted spec — worth confirming with a Digital Turbine contact before a large campaign.
What DT Exchange's own docs confirm about playables
Digital Turbine publishes an "Ad Types and Specification" reference in its official docs (docs.digitalturbine.com) that lists a Rewarded Playable as one of its supported creative types, distinct from Rewarded Video and Interstitial Display. The confirmed details, quoted directly from that page:
- Placement & size: Full Screen, shown as a Modal placement.
- Duration cap: 30 seconds maximum.
- Supported ad content: "HTML/MRAID 2.0, VAST 2.0" — so a playable is expected to be a standard MRAID 2.0-compliant HTML creative, not a proprietary DT-only wrapper.
- Close behavior: a DSP can call MRAID 2.0's
useCustomClose()to present its own close UI before the 30-second mark ends. IfuseCustomClose()is detected, the DT SDK adds a fail-safe Close button after a 30-second delay regardless, so the user is never permanently stuck in the creative.
| Requirement | What DT Exchange publishes | Publicly confirmed? |
|---|---|---|
| Ad content type | HTML / MRAID 2.0, VAST 2.0 | Yes |
| Placement / size | Full Screen, Modal | Yes |
| Duration cap | 30 seconds maximum | Yes |
| Close button logic | MRAID.useCustomClose(), fail-safe close at 30s | Yes |
| Max file size | Not stated on the public spec page | No |
| Package format (ZIP vs. single HTML) | Not stated on the public spec page | No |
| Named click-through / CTA function | Not stated beyond "MRAID 2.0" generally | No |
What's genuinely unclear — and why that matters more than it sounds
This is the part worth being upfront about. Unlike Google, Mintegral, or Vungle — which each publish an exact file-size ceiling and a named click-through function in their creative specs — DT Exchange's public documentation confirms the creative type (HTML/MRAID 2.0) and the runtime behavior (duration, close button) but does not publish a specific maximum file size for playables, nor does it name a DT-specific click-through function the way Mintegral names window.install() or TikTok names openAppStore().
That's not an oversight on our part — it's the actual state of DT Exchange's public docs as of this writing. Two things follow from that:
- Because the supported content is standard MRAID 2.0, the click-through almost certainly resolves to the standard MRAID
mraid.open()call rather than a proprietary SDK method — that's the whole point of building to MRAID instead of a custom API. Treat this as a reasonable inference from what MRAID 2.0 support implies, not as a line quoted from DT's spec page. - With no published size ceiling, the safest move is to build to the general cross-network norm most exchanges converge on — creatives well under 5 MB, ideally closer to 2 MB — and confirm the exact cap with your DT Exchange account or publisher contact before a large campaign, rather than assuming a number that isn't actually published.
Adapting a Playworks/Luna export for DT Exchange today
Playworks/Luna exports a working playable as a ZIP with an HTML entry point plus its engine assets. To get that in front of DT Exchange manually, based on what's confirmed above:
- Make sure the build is a self-contained, standard MRAID 2.0 HTML creative — no dependency on a network-specific SDK global that DT Exchange doesn't document.
- Wire the CTA through
mraid.open()rather than a network-proprietary call, consistent with DT Exchange's stated "HTML/MRAID 2.0" support. - Respect the 30-second interaction window in your own creative logic if you want control over the close moment, and call
mraid.useCustomClose()if you're presenting a custom close UI — otherwise DT's fail-safe close will appear at 30 seconds regardless. - Keep total asset weight conservative (aim under ~2–5 MB) since no published ceiling exists to build against, and verify actual limits with DT Exchange directly before a real submission.
None of that is DT-Exchange-specific tooling — it's the same MRAID discipline a Playworks/Luna export already needs for AppLovin or Unity Ads. That's also exactly the kind of per-network wiring PlayableKit automates for the networks it currently supports.
What PlayableKit supports today
From the same Playworks/Luna export ZIP, PlayableKit currently generates network-compliant packages for the networks it supports — correct clickTag/MRAID/SDK wiring, asset encoding, and package shape handled per network's actual published rules. DT Exchange isn't one of them yet; when it's added, it'll follow the same confirmed specs laid out above rather than guesswork.