The AdGem Offerwall: Four Ways In

How publishers integrate with AdGem, and the single idea that ties the four integration models together.

This is the pre-read for the Offerwall Integration Models onboarding session. Read it beforehand so the session itself can be a discussion rather than a lecture. You don't need to memorize API fields. What matters is the shape of the system, how the pieces relate, and how we reason about which model a publisher ends up on.

Audience: engineers joining AdGem, particularly anyone landing in or adjacent to Publisher Integrations.

First, what's an offerwall?

An offerwall is a rewarded catalog. Users complete offers (install a game, reach a level, take a survey) and earn the publisher's in-app currency.

Four parties are involved:

Party	Role
Advertiser	Pays for completed actions
AdGem	Supplies the technology
Publisher	Shows the wall to their users
User	Completes the offer

Money flows advertiser → AdGem → publisher, and the user gets rewarded along the way. You'll hear advertisers called demand and publishers called supply constantly, so it's worth internalizing that vocabulary early.

A publisher (a game, a rewards app) wants to reward its users. We supply the offers and the technology to attribute completions and trigger payout. Postbacks tell the publisher when a user finished an offer. Everything below is just how a publisher plugs into that.

One naming note: the offerwall UI is now called AdGem Arcade. It was previously the "Reward Ad Unit," and you'll still find the old name in older documents.

The mental model: one stack, four entry points

This is the whole thing in one picture. We do not have four unrelated products. We have one layered stack, and a publisher can tap into it at any layer.

At the bottom sits the Offer API, the raw catalog. Prism layers intelligence on top of it. Above that is our own UI, AdGem Arcade, delivered two ways: as an iframe on the web, and natively through the SDK.

The deeper you tap in, the more you consume from us. The higher you tap in, the more you build yourself.

The one axis

If you remember one thing from this page, remember this:

How much does the publisher want to build versus consume?

Everything else (platform, engineering capacity, time-to-revenue, control) is a modifier on that single axis. A publisher that wants to build nothing takes AdGem Arcade via iframe or SDK. One that wants total control takes the raw Offer API. Prism is the middle: our brains, their UI.

The four models

Offer API — the raw catalog

Our full catalog over REST. No UI, no per-user intelligence.

• What it is: the whole offer catalog plus rich metadata over REST. Publishers poll every 5 to 10 minutes; it is not real-time.
• Publisher owns: ranking, personalization, suppression, and the UI. Everything.
• We provide: the catalog, coarse filters, the network_epc performance signal, and click/postback plumbing.
• Fit: L4–L5 and data-sophisticated teams. Highest engineering lift, slowest to revenue.

This is the foundation, and the untargeted counterpart to Prism: all offers, no scoring. We expose network_epc as a signal, but the publisher builds the ranking themselves. The sweet spot is a team with its own ML and ranking stack, or one dropping a handful of offers into a featured section.

Worth flagging early: this is the exception, not what we lead with. More on why below.

Prism — our brains, their UI

Per-user personalization over GraphQL. The engine behind our own AdGem Arcade.

• What it is: scores, ranks, and suppresses offers per user, served over GraphQL.
• Publisher owns: the UI, and they keep final ranking control. We hand back a ranked list.
• Why it matters: validated RPC lift (Spearman 0.90), localization built in, and it improves centrally for everyone.
• Fit: L3–L4 publishers with strong brand or UX requirements. The first external publisher (ZipRewards) is live.

Prism (formerly the Targeted API) is the best-of-both option, and it's our moat. The publisher gets our intelligence as an input while keeping their own frontend: query GraphQL, request only the fields they need, render in their own UI. Prism consumes the Offer API and adds the intelligence layer on top, and it's also what powers the iframe and the SDK.

AdGem Arcade on Web — drop-in

Our full offerwall UI via iframe, WebView, or direct link. Powered by Prism.

• What it is: our rendered Arcade, embedded into web pages and app WebViews.
• Publisher owns: a slot, currency branding, and playerid substitution. We own the rest.
• Strengths: fastest to revenue, near-zero lift, supports segmentation, Reward Status built in.
• Tradeoff: limited UI customization (currency and header image only), and ranking is ours.

This is the easy path, and what we currently lead with. Drop in a link and we render everything. On the web it's near-zero effort. Inside an app WebView it's somewhat more work (sizing plus click-out boilerplate), which is precisely the argument for the SDK. It's self-serve from the dashboard once the app is approved.

SDK — drop-in, native

The same AdGem Arcade, wrapped natively. iOS, Android, and Unity.

• What it is: wraps our Arcade web view, handling the JS bridge and click-out boilerplate.
• Publisher owns: dropping in the SDK and a CTA button. We own catalog, intelligence, UI, and integration.
• Why SDK over iframe: the boilerplate is done for them, updates arrive via package bump, and we get higher-quality device data.
• Today: no segmentation yet (single app_id), plus observability gaps. Publisher Integrations owns the roadmap.

Same UI as the iframe, delivered natively. UI improvements ship without an app release, since the content is web-rendered inside the container; only wrapper changes require a release.

The honest current state: functional but gapped. There's no multi-placement support, no device-level suppression, and no observability into silent failures. That's why the SDK isn't yet what we lead with, even though leadership wants it to be primary.

The four, at a glance

	Offer API	Prism	iframe	SDK
One-liner	Raw catalog	Brains, their UI	Our UI (web)	Our UI (native)
UI owner	Publisher	Publisher	AdGem	AdGem
Personalization	Publisher builds	AdGem (Prism)	AdGem (Prism)	AdGem (Prism)
Ranking control	Publisher (total)	Publisher (final)	AdGem	AdGem
Platform	Any	Any (web-lean)	Web + WebView	iOS/Android/Unity
Segmentation	Yes	Yes	Yes	Not yet
Eng lift	Highest	Medium	Lowest	Low
Time-to-revenue	Slowest	Medium	Fastest	Fast

Read it left to right: moving from the Offer API toward the SDK, the publisher builds less and we provide more, and control shifts from them to us. Segmentation is the one place the SDK is currently behind. Don't memorize this table, just know where to find it.

Which model when

The routing logic is a short decision tree:

1. Do they want our AdGem Arcade, or their own UI?
2. If our UI: do they need segments? Yes → iframe. No → still iframe today, with the SDK for the SDK-inclined.
3. If their UI: do they want our personalization? Yes → Prism. No → Offer API, by exception.
4. Tiebreakers, in order: platform, control appetite, engineering capacity, urgency.

The first fork is really "do they want to build a frontend at all?" If not, it's iframe or SDK. If so, the question becomes whether they want our personalization, and the answer is almost always yes, which means Prism.

Why it's ordered this way: Prism is the middle, and the moat

You're an engineer, not a salesperson, so keep this light. It's still useful to know why we invest where we do, because it shapes what we build.

• Default reflex: lead with AdGem Arcade. Reach for Prism when the publisher wants their own UI.
• Prism is the moat. Our intelligence is the sticky, differentiated layer.
• Offer API is by-exception. A raw catalog is commoditized, and leading with it leaves our actual value on the table.
• "They asked for an API" usually means they want Prism, not the raw catalog.

So when someone asks for "the API," the reflex should be: I have Prism, tell me why it can't be Prism. Offer API comes only after a real technical conversation.

Migration is a feature, not a failure

Publishers move between layers, and that's the stack working as designed rather than something going wrong. Because it's one stack, moving is a small change instead of a re-integration.

Move	Why a publisher does it
Offer API → Prism	Stop maintaining their own ranking and suppression
iframe/SDK → Prism	Outgrew our UI, want to keep our brains
Prism → iframe/SDK	Decided they didn't need a custom UI after all

Move up the stack to offload work; move down to take control. This is both a selling point and an architecture principle.

The road ahead

An honest forward look at where this is going.

• SDK-primary is the aspiration, not today's posture. The category leads with SDK (Adjoe, Tapjoy, DT), and a weak SDK reads as immaturity.
• The gate: runtime init, multiple placements, observability, and the ANR/bug backlog all need to be resolved first.
• Prism-in-SDK is the big unlock. Native rendering of Prism results, currently in co-development with Toss. Install the SDK, get Prism-powered offers inside your own native UI.
• Today: iframe leads, Prism is ramping with its first external publisher live, and the SDK is being battle-tested.

Until the SDK readiness gates ship, we route by fit rather than by preference.

How this shows up in your work

• Publisher Integrations owns the SDK roadmap, the Ivan/Nineva relationship, and SDK PR review.
• Public docs: docs.adgem.com carries the iOS, Android, Offer API, and Prism guides.
• Endpoints you'll hear about: offer-api.adgem.com (REST) and targeted-api.adgem.com (Prism, GraphQL with JWT).
• Our stack: Arcade is a Vue.js app; most services are PHP/Laravel.
• Support path: Publisher Integrations engineers are first line, Ivan is second line.

The SDK is maintained with a contractor (Ivan) plus an incoming full-time mobile hire. When a publisher integration breaks, it routes through us first.

Bringing it home

• One stack, four entry points: Offer API → Prism → AdGem Arcade (iframe / SDK).
• The one axis: build versus consume.
• Prism is the middle and the moat. iframe leads today; the SDK is the aspiration.

If you hold onto the picture and the one axis, you can place almost any integration conversation you overhear.

Go deeper

• Gus's integration canvases in Slack #team-pub-ints (C05HJ6PCEN5) carry per-model technical profiles, current state, and known gaps.
• docs.adgem.com for the public integration guides.