Skip to content
Open Portal

Troubleshooting

Fix the most common integration issues.

Applies to Appylar v1.0

Fixes for the most common issues when integrating the SDKs or running campaigns. Each entry lists the problem, the likely cause, and the solution.

#SDK won't initialize

Problem. Ads never load; callbacks report NOT_INITIALIZED (.notInitialized on iOS).

Cause. Appylar.initialize(...) hasn't run before the first ad request, or it threw because the app key was blank.

Solution. Call initialize once at startup (Application.onCreate on Android, app launch on iOS) with a non-blank key. It's non-blocking, so do it as early as possible so a token is ready before you request an ad.

#Invalid app key

Problem. Initialization seems fine but nothing ever fills; logs show authentication failures.

Cause. The app key is wrong, belongs to a different app, or was invalidated by a key rotation.

Solution. Copy the current key from the app's detail page in Apps. If you rotated the key, released builds using the old key stop working — ship an update with the new key. Use LogLevel.DEBUG / .debug to see the failure.

#No fill

Problem. onFailedToLoad(NO_FILL) / didFailToLoad(.noFill).

Cause. There's no eligible ad to show at that moment. This is expected, not a bug — but if you always get no-fill while testing, it usually means there's no eligible inventory yet.

Solution. To exercise the integration immediately, initialize with testMode to get deterministic test ads regardless of live inventory. To see a real fill you need eligible inventory:

  • Portfolio: a campaign never serves in the app it promotes, so you need at least two apps — one shows the ad promoting the other.
  • Network: turn on Network Exchange in Settings for your organization and opt the app in, and make sure the advertiser has credits.

Otherwise, treat NO_FILL as normal and simply don't show an ad.

#Creative stuck pending

Problem. Your campaign is active but nothing serves; the creative shows pending.

Cause. The creative hasn't been reviewed yet. Pending creatives never serve.

Solution. Wait for moderation to complete. It's manual during the design-partner phase, so it isn't instant. See Creatives.

#Creative rejected

Problem. The creative shows rejected and won't serve.

Cause. It didn't pass review — the campaign page shows the exact reason (e.g. misleading content, low quality, text overlapping the safe area).

Solution. Fix the issue and upload a new image. That resets the status to pending for another review.

#Campaign not serving

Problem. Everything looks set up but you see zero impressions in Analytics.

Cause. One of the serving prerequisites is missing.

Solution. Check all of these:

  • The creative is approved (not pending/rejected).
  • The campaign status is active (activate it if it's draft/paused).
  • For network reach, your credit balance is above zero.
  • Your date/geo/frequency settings aren't excluding the traffic you expect.

#Network disabled

Problem. A network campaign doesn't reach the wider network.

Cause. Network serving requires two switches, and the organization-wide one is off by default: the org-level Network Exchange, and the per-app opt-in. If either is off, network campaigns silently don't serve or receive ads.

Solution. Turn on Network Exchange for your organization in Settings (this is the master switch and starts off), and opt the app in as well. Portfolio reach doesn't need either.

#Out of credits

Problem. A network campaign served for a while, then stopped.

Cause. Your credit balance reached zero, so network serving paused automatically.

Solution. Buy more credits on Billing. Portfolio campaigns keep serving regardless of balance.

#Frequency cap reached

Problem. Impressions are lower than expected for engaged users.

Cause. The campaign's frequency cap limits how often the same user sees your creative per day.

Solution. Raise or remove the cap if you want more impressions per user — but a cap usually improves reach across more users.

Problem. The banner renders but the image looks off.

Cause. The banner scales the served creative to fit its container; an oddly sized container distorts perceived layout.

Solution. Give the banner a sensible size with layout params (Android) or Auto Layout constraints (iOS). The creative scales aspect-fit within it. See Android / iOS.

#Unauthorized (401)

Problem. REST API requests return 401 after previously working.

Cause. The bearer token was revoked (you logged out) or is wrong. For the SDKs, the short-lived serving token simply expired.

Solution. For the REST API, log in again to get a fresh token and resend the request — don't hard-code a token. The SDKs refresh their serving token automatically; you never manage it yourself.

#Rate limited (429)

Problem. Requests return 429.

Cause. You exceeded the per-minute rate limit. Auth, token, serve and events endpoints are throttled.

Solution. Back off and retry after a short delay. The SDKs already queue and retry events with backoff, so you rarely hit this through them — it usually means a script is polling too aggressively. Don't call the API in a tight loop.

#Callbacks or delegates never fire

Problem. onLoaded / onFailedToLoad (Android) or the delegate methods (iOS) don't fire.

Cause. The listener/delegate was set after load() (or after the banner was added to the view), or the interstitial/delegate was released before the callback arrived.

Solution. Set the listener/delegate before calling load() and before adding a banner to the view, and keep a strong reference to the interstitial until it's dismissed. Callbacks are always delivered on the main thread. See Android / iOS.