Show ads from your account in your own Android app, video/audio player, or any standards-based ad integration — no WebView, no iframe. Uses the same slot keys as your website embed code. Android SDK below (§1–10); VAST/DAAST/Native for any other player at §11.
The Android SDK talks to a JSON version of the same ad-serving endpoint your website embed uses (serve.php / click.php). It renders the returned ad with native Android views — TextView, ImageView, or a Media3 player for audio/video — styled to match the colors and font you picked when creating the site/placement.
minSdk 24 or higher<uses-permission android:name="android.permission.INTERNET"/> in your app's manifest — easy to forget, and ads will silently fail to load without itThe SDK currently ships as source — a Gradle module you include directly in your project, not yet a published package.
adsdk folder.app module.settings.gradle.kts:
build.gradle.kts:
The zip also includes a short README.md with the same steps plus the quick-start code below, in case you're setting this up without this page open.
Initialize once, e.g. in your Application class:
Add an AdView to your layout:
Load an ad:
Log in to see your real slot keys here. Everything above this section works the same whether you're logged in or not — this is just a shortcut so you don't have to copy keys from My Sites by hand.
| Ad type | Rendered as |
|---|---|
| text | Styled headline + body text |
| image | Image with optional headline/body text |
| audio | Media3 (ExoPlayer) audio player with title/CTA |
| video | Media3 (ExoPlayer) video surface, autoplay muted with tap-to-unmute |
Every video ad is server-side transcoded to one consistent resolution/frame-rate/bitrate (admin-configured) before it can air, and capped at 30 seconds — so a player showing several video ads back to back (e.g. a VAST pod) never sees a resolution, frame-rate, or audio jump between them.
A placement's ad format (text/image, video, or audio) is fixed per slot — the same choice you made under My Sites — so a given AdView only ever loads compatible ads.
Background, text, accent, and border colors plus corner radius come from your slot's style settings automatically — no extra code needed. Two things don't map perfectly to native Android and are documented limitations, not bugs:
Teaser display style — if a site's display style is set to "Teaser" under My Sites, AdView continuously animates the whole ad unit the same way the web embed does, picking the animation from the slot's teaser animation setting:
| Teaser animation | Native behavior |
|---|---|
| pulse | Gently scales the ad up and down (1.6s cycle) |
| glow | A pulsing colored border overlay (1.8s cycle) — Android has no direct equivalent of a CSS box-shadow glow, so this is a deliberate visual approximation, same fixed color the web version uses |
| shake | A small side-to-side shake (2.4s cycle) |
A "Standard" display style (the default) has no animation. This applies to every ad type — text, image, audio, and video all animate the same way when teaser is on, matching the web embed's behavior of animating the whole ad container regardless of what's inside it. A slot set to one of the newer web-only animations (bounce, wobble, flash) renders statically in the SDK — no crash, just no motion — until a future SDK release adds them.
When a user taps an ad, the SDK fires the click-tracking request in the background (never blocking or delaying anything) and immediately opens the destination URL in a Chrome Custom Tab, falling back to a normal browser intent if Custom Tabs isn't available. A slow or dropped tracking ping never affects what the user sees.
If a slot has auto-refresh enabled, AdView automatically loads a new ad on that interval while it's attached to the window, and stops when it's detached (e.g. the screen is left).
Any failure — network error, no eligible ad, malformed response — is handled the same way: AdView hides itself (visibility = GONE) and calls onAdListener.onAdFailedToLoad(reason). It never throws or crashes your app.
For video and audio you don't need the Android SDK at all — any player that speaks the industry-standard ad templates can pull ads directly. Text/image already is a native ad format, via the same JSON API below.
Video — VAST 4.0
Works with Google IMA SDK (web/Android/iOS), ExoPlayer's IMA extension, Video.js + videojs-contrib-ads, JW Player, and any other VAST 4.0-compliant player. Only slots with ad format "Video" return a real ad — anything else, or nothing eligible, returns a spec-valid empty <VAST/> document, never an error.
Ad pods: a request returns every currently eligible video ad for that slot, one per <Ad> element with an incrementing sequence, up to max (default 4, hard-capped at 10 regardless of what you pass — protects both your player and this server from an oversized response). Fewer eligible ads than the cap is fine, that's just a smaller pod; house ads fill any remaining slots the same way they fill a single-ad request. Each <Ad> is its own real impression with its own credit, exactly as if the player had made that many separate requests — a genuine 3-ad pod shown to one viewer is 3 real impressions, not the same one 3 times. Most players play a pod back-to-back as one ad break; if yours only understands a single ad, pass max=1 to get exactly one <Ad>.
Audio — DAAST 1.0
The IAB's audio-ad counterpart to VAST — same idea, <DAAST> root, <AudioClicks> instead of <VideoClicks>, same pod/max behavior described above. Works with podcast/streaming ad-insertion tools and any DAAST-aware player. Only slots with ad format "Audio" return a real ad.
Text & image — already a native ad format
No separate endpoint needed — the JSON from /api/serve.php (§12 below) already returns exactly what the IAB's Native Ad concept describes: a headline, body text, an image URL, and a destination link, as plain JSON instead of XML. Any native-ad rendering integration can consume it directly.
Scope, honestly
<Impression> pixel is included because compliant players expect one, but nothing depends on it actually firing.<MediaFile> width/height always reflect the real, current admin-configured target resolution — every video ad is transcoded to exactly that size, never a guess.For reference, or if you're integrating from something other than the Android SDK. Requests are unauthenticated aside from the slot key itself, matching the website embed.
GET https://adserver.unlimitedtextads.com/api/serve.php?slot={key}&pid={optional}&app_id={optional}
slot — required, your 32-character slot keypid — optional correlation id used to cap credited impressions per logical page/screen (the SDK generates one automatically per AdView)app_id — optional, your app's package name, used only as a fallback if pid is absentPOST https://adserver.unlimitedtextads.com/api/click.php?imp={impression_token}
Always responds {"status":"ok"} (HTTP 200), even for an unknown or expired token — fire this in the background and open the ad's destination_url immediately, don't wait for the response.
API traffic goes through the same fraud checks as the website embed (bot filtering, rate limiting, duplicate-impression detection, self-traffic detection). A flagged impression or click still renders/redirects normally — it's simply not credited.
Every site/slot you create under My Sites has a placement type, chosen when you create or edit it. All of them use the exact same embed tag shape — <script async src=".../embed.js?slot={key}"></script> — the server decides how to render it based on what you picked, so there's nothing extra to configure in your page's code.
| Placement | Markup needed | Behavior |
|---|---|---|
| Inline | A sized <div id="adserver-{key}">, same as always | Renders in that exact spot — the original placement type, unchanged. |
| Sticky banner | Just the script tag, no div | Pinned to the top or bottom of the viewport, full width, stays visible while scrolling. |
| In-page push | Just the script tag | A notification-style card appears in the bottom-right corner a couple seconds after load, auto-dismisses, frequency-capped per visitor. |
| Interstitial | Just the script tag | Covers the full page; a close button appears after your configured delay. Frequency-capped — this is the most intrusive format, use sparingly. |
| Popunder | Just the script tag, anywhere on the page | No visible ad unit at all. On the visitor's first click anywhere on the page, opens a new tab to the advertiser's page. Frequency-capped per visitor. |
| Rewarded video | The script tag, plus your own trigger calling AdServerRewarded.show() (§15) | Not shown automatically — you call it from your own UI (e.g. a "Watch an ad for a bonus" button). |
Frequency caps are tracked client-side (localStorage) per browser, not server-enforced — good enough to stop the same visitor being hit repeatedly, not meant to be unbeatable.
Rewarded video is the one placement type your own page code triggers directly, since only you know when a visitor has earned it (e.g. clicked "Watch an ad for 10 extra credits"). embed.js exposes a global for this — include the same script tag as any other slot, then call:
The player shows a small "× Skip" button throughout — closing early is always allowed, it just means onReward never fires for that view. Watch progress is reported to the server every few seconds during playback and checked against the server's own record of the video's real duration; onReward only fires once that crosses ~90% watched, never from the player's local "video ended" event alone — see the source comments in api/rewarded-progress.php if you're curious why that distinction matters.
This is a different API from everything above §1–15. The Android SDK and VAST/DAAST/JSON endpoints let any app display ads from your slots — no login, keyed only by a slot's public key. The Member Account API below is the opposite: it's how you monitor and manage your own account (ads, sites, balance, stats) from your own app, the same things you'd otherwise do by logging into this website. Build a personal Android app against it, or use it from a script — anything that can send an HTTP request.
The website itself authenticates with a session cookie, which a native app has no equivalent of. This API uses a Bearer token instead: log in once, get back a long-lived token, then send it on every other request. Log in again from a second device (e.g. a phone and a tablet) and both tokens stay valid independently — logging out on one doesn't affect the other.
Response:
device_label is optional — it's just a note stored with the token so a future "manage logged-in devices" screen could tell them apart; nothing reads it today. Store the token somewhere secure on-device (Android: EncryptedSharedPreferences, not plain SharedPreferences) and send it as a header on every other /api/member/* call:
A missing or invalid token gets a 401 with { "status": "error", "message": "..." } — treat that as "send the user back to the login screen." POST /api/member/logout.php (with the header) revokes just that one token.
Prefer "Continue with Google" instead of a password? login-google.php issues the same kind of token, given a Google ID token instead of a password:
Response shape is identical to login.php above. On Android, request the ID token via Credential Manager's Sign in with Google, passing this site's own Google client ID as serverClientId — 388009720513-vt61i8r4tp3d2fbj4uqcjs7cp7a24u9b.apps.googleusercontent.com — so the token's audience matches what the server verifies against. First sign-in creates a member automatically (same signup bonus as the regular signup form); an existing password-based account with the same email is matched and reused rather than duplicated.
All requests/responses are JSON. All except login.php and login-google.php require the Authorization: Bearer header above. POST endpoints accept either a JSON body or regular form fields.
| Endpoint | Body / query | Returns |
|---|---|---|
POST login.php | email, password, device_label? | token + your member profile |
POST login-google.php | id_token, device_label? | token + your member profile (same shape as login.php) |
POST logout.php | (none) | revokes the current token |
GET me.php | (none) | your profile & current credit balance |
GET dashboard.php | (none) | balance, earned/spent totals, active ad/site counts, 14-day impressions/clicks chart, top pages, browser/country breakdowns — same numbers as your web dashboard |
GET ads.php | (none) | all your ads — status, creative, weight, lifetime impressions/clicks |
POST ads-status.php | ad_id, action (pause|resume) | the updated ad. 409 if the ad isn't in a state that allows it — e.g. you can't resume an ad still pending admin review |
GET slots.php | (none) | all your sites/placements — status, format, lifetime stats, and the exact embed_snippet to paste on a site |
POST slots-status.php | slot_id, action (pause|resume) | the updated site/slot |
GET ledger.php?limit= | limit optional, default 50, max 200 | recent credit ledger entries (earnings, spend, bonuses) — same feed as the dashboard's activity list |
Creating new ads/sites or editing their creative and styling isn't exposed here yet — those still go through the web app, which also handles file uploads (images/audio/video) that a JSON API would need a separate multipart flow for. Everything about monitoring and pausing/resuming what you already have is covered above.
A minimal reference client — plain OkHttp + org.json, the same libraries the Android SDK above uses, so there's nothing new to add if you're already building against it. This is deliberately small: enough to log in, list ads/sites, and toggle status, so you can see the shape of it and build your own screens around it.
Run every call off the main thread (e.g. inside viewModelScope.launch(Dispatchers.IO)) — OkHttpClient.newCall().execute() above is blocking, same as the SDK's own network layer. Persist token across app restarts (encrypted storage) so the user isn't asked to log in every time; call me.php on launch to confirm it's still valid before showing cached data.