Wrapper Not Loading
Symptom: typeof window.Wrapp === 'undefined' in the browser console, or window.Wrapp exists but no AAM logs appear even with ?pbjs_debug=true, or you see Wrapper bootstrap failed: errors.
This page walks from fastest to deepest check.
Quick checks (5 min)
1. Is the tag actually in the page?
View page source (Ctrl/Cmd + U). Search for your domain ID. The inline <script> block you pasted should be there.
If not:
- Full-page cache is serving old HTML — purge your CDN / CMS cache and retry
- The tag was pasted in a template that doesn't actually load on the page you're checking — confirm it's in the shared layout or header include
- The template wraps the tag conditionally (consent gate, A/B test, env check) that's currently skipping it
2. Are the network requests going out?
DevTools → Network, reload, filter by jsdelivr or your domain ID. You should see three requests:
| Request | Expected |
|---|---|
data.jsdelivr.com/v1/package/npm/@<org>/<domain-id> | 200 (or 304) |
cdn.jsdelivr.net/npm/@<org>/<domain-id>@<version>/dist/wrapp-<domain-id>.js | 200 |
<env-domain>/api/portal/v1/configs/<domain-id>/ | 200 |
If any of them are missing or failing, that's your lead. Jump to the matching section below.
3. Is debug mode actually on?
Append ?pbjs_debug=true to the URL. Filter Console for AAM. If you see AAM Processing <N> ad slots on page, the wrapper is fine — your issue is elsewhere (e.g. a layout didn't match, no bidders are wired up).
Diagnosis (15 min)
Case A — window.Wrapp is undefined
The library script didn't finish loading.
Check the jsDelivr request.
| Result | Cause | Fix |
|---|---|---|
| Request never made | Inline tag not running | Re-confirm the tag is in <head> and not inside a conditional block |
| Request blocked (red in Network) | CSP, ad blocker, or privacy extension | Whitelist cdn.jsdelivr.net and data.jsdelivr.com; test with extensions disabled |
| 4xx | Domain ID mismatch | Confirm the domain ID in the tag matches the domain in Account → Setup → Wrapper |
| 5xx | jsDelivr temporary outage | Check status.jsdelivr.com, retry |
| Times out | Network path problem | Test from another network; confirm your CSP isn't stalling the connection |
Case B — window.Wrapp exists, no AAM logs, no __wrapp_loader
The library loaded but the inline loader never called bootstrap().
Usually that means the config fetch threw synchronously and the loader's error branch didn't recover. Check Console for any red errors, then:
- Look at the config request (
<env-domain>/api/portal/v1/configs/<domain-id>/) in Network - 4xx or 5xx: confirm your domain is provisioned and the config endpoint is healthy (your onboarding specialist can check)
- Blocked by CSP: whitelist the env domain
Case C — window.Wrapp exists, __wrapp_loader set, but no ads
Bootstrap ran. Look at the loader telemetry:
window.__wrapp_loader
// { library_load_ms: …, config_fetch_ms: …, config_source: …, loader_start: … }
config_source | Meaning |
|---|---|
network | Fresh config fetched — healthy path |
cache | Network fetch failed; serving last-known config from localStorage |
config_source is only ever network or cache. If the config fetch fails and localStorage has nothing usable, the wrapper never bootstraps — so window.__wrapp_loader is absent entirely rather than showing another value.
If config_source is cache persistently, the config endpoint is failing (the wrapper is coasting on the last cached config). If window.__wrapp_loader is missing altogether, the fetch failed on a first visit with nothing cached — most likely a broken config endpoint.
Case D — Wrapper bootstrap failed: … in Console
The library ran bootstrap(config) and it threw. The error message that follows is the signal:
| Error snippet | Likely cause | Fix |
|---|---|---|
inventory defined for different domain with ID '…' | Cached config from a different domain | Clear localStorage; reload |
Property errors (Cannot read property 'x' of undefined) | Config shape mismatch with library version | Deploy a current release from Wrapper → Releases to refresh config |
setTargetingForGPTAsync is undefined | Prebid didn't initialize before wrapper tried to set targeting | Check for Prebid version conflicts; confirm the Prebid bundle in the wrapper build is intact |
Case E — googletag (google publisher tag) did not load properly
GPT itself didn't load. The wrapper depends on GPT for ad rendering.
| Check | Fix |
|---|---|
Is securepubads.g.doubleclick.net blocked? | CSP or ad blocker — whitelist |
| Is GPT loaded elsewhere on the page? | Duplicate-load race — typically benign, but collisions can break rendering |
| Network errors on the GPT request? | Browser / network-side issue; test in another browser |
Fix and verify
After each attempted fix:
- Clear browser cache (or use incognito)
- Reload the page with
?pbjs_debug=true - Filter Console for AAM
- Expect
AAM Processing <N> ad slots on pagewith N matching your layout
If N is 0 even though the wrapper is healthy, the layout didn't match your page URL — check Inventory → Layouts → the layout's page-path pattern against the URL you're testing.
When to escalate
Escalate to your onboarding specialist or support@animaadtech.com if:
- The config endpoint (
/api/portal/v1/configs/<domain-id>/) returns a persistent 5xx - The jsDelivr library request returns 404 for a valid domain ID (may indicate a broken build)
Wrapper bootstrap failed:errors persist after deploying a fresh release
Include when you escalate:
- Your domain ID
- The output of
window.__wrapp_loaderfrom the affected page - The full Console log from a reload with
?pbjs_debug=true - The URL you're testing and what layout you expect it to match
Related
- Wrapper Debugging — the complete reference of signals
- Verifying installation — the healthy-path checks
- Ads not showing — if the wrapper loads but ads still don't render