Authorized selling, continuously enforced.
Unauthorized reselling and spoofing cost publishers revenue and cost buyers trust. app-ads.txt is the industry's fix: a plain text file that declares who may sell your inventory, crawled and honored by honest platforms. Declaring it once is easy; keeping it correct across every app, every store and every network change is ongoing work that most teams do badly by hand. This page covers the tooling we run it with, the enforcement we apply on our own buying, and the failure modes our monitoring catches before buyers do.
Crawl · validate · filter · every cycle
Inventory gets resold that was never authorized.
Spoofing is not a theoretical risk in programmatic advertising; it is a standing business model on the other side of every unguarded bid request. Three facts keep it alive.
What spoofing costs buyers
A bid request claiming your app can win programmatic budget without your knowledge, because nothing on the request proves where it was born. The buyer pays for inventory the publisher never authorized to sell. Every spoofed dollar teaches the buyer to trust your app less, which is the part that lasts.
What it costs publishers
Unauthorized sellers dilute the value of legitimate demand for your impressions, since buyers cannot distinguish the counterfeit path from the real one at bid time. Your inventory trades at the counterfeit price in parallel with the real one. Authorized-only buying is what reunites the two markets, and it only works when the declaration is correct.
Why it persists
The fix is unglamorous: a text file that must exist, stay correct, and cover every app on every store listing you own. Files drift out of date when networks are added or dropped, and drift reopens the door one app at a time. The industry does not have a knowledge problem here; it has a maintenance problem, which is exactly the kind automation solves well.
The IAB spec, translated into plain words.
One text file at the root of your developer website listing every ad system authorized to sell your inventory, with the account ID and the relationship. Buyers crawl it, and honest platforms filter bid requests against it, so an unauthorized path simply stops clearing. The full syntax, hosting requirements and failure modes are covered in the definitive guide.
One line authorizes one ad system for one developer
We only buy from authorized sellers.
Incoming bid requests are checked against the app-ads.txt declaration resolved from each store listing's website field. A request whose seller is not authorized for that app is filtered before the auction, before it can clear, not after it gets paid. Enforcement runs continuously against current crawls, so a file change propagates into filtering without manual intervention, in both directions: a new authorized line starts clearing on the next crawl, and a removed line stops.
The same standard applies to the supply we offer others. Our account IDs in your files are the ones our sellers.json registry backs, and our own declarations are available from your account manager, so anyone can hold us to the rule we apply to everyone else. The trust page documents the full mechanism.
Per app, in the dashboard: file state at a glance.
The tool exists because manual file maintenance fails quietly. It watches every app on the account, flags drift the crawl after it happens, and hands you the fix next to the finding.
File status and crawl time
Each app shows whether a file was found, where the store listing resolved it, and when it was last crawled. Drift becomes a visible state with a timestamp instead of a discovery made during a buyer escalation. The status updates on every crawl cycle.
Detected errors
Malformed lines, wrong publisher IDs, unauthorized lines and BOM bytes are flagged per line, with the fix written next to the finding. The tool does not just say the file is broken; it says which line, why, and what the corrected line looks like. Findings link straight to the generator for the corrected output.
Auto-generated lines
The correct Sky Boosts line for each app is generated with your account ID, ready to paste into the file at your developer domain. The same generator is available publicly, so you can produce lines for every network you work with, not only ours. No hand-editing IDs at midnight before a launch.
Re-crawls and alerts
Files are re-crawled on a schedule and on demand. Mismatches between the file and the apps actually monetizing on your account trigger alerts by email and in the dashboard, with the specific app and the specific line named. Silence from the monitor means the files are clean, because silence is engineered to mean that.
Every app on the account
The tool tracks every app on the account automatically, so coverage never depends on someone remembering to add a listing. A new store listing without a file shows up as a finding on day one, before it has had a chance to monetize unauthorized. Coverage gaps are the classic failure of manual maintenance, so coverage is the first thing the tool automates.
The usual ways files go wrong.
Most app-ads.txt problems are one of six things, and five of them are invisible until a crawler tells you. This is the list our monitoring works from, with the symptom and the fix for each.
| Error | Symptom | Fix |
|---|---|---|
| Missing file | 404 at the developer domain root | Publish app-ads.txt, verify over HTTPS. If your site builder cannot serve a root file, host it on any static host under your domain and point the store listing's website field there |
| Empty website field | Nothing to crawl; discovery fails silently | Set the developer website in the store console |
| Wrong publisher ID | File exists, line does not match the account | Regenerate the line with your account ID |
| BOM (byte order mark) bytes | First record rejected by some crawlers | Save as UTF-8 without BOM |
| Wrong MIME or subdirectory | File served as HTML or under a path | Serve text/plain at the domain root |
| Stale entries | Removed systems still authorized | Re-issue the file from the current account list |
How a buyer verifies the full path.
The sellers.json registry we maintain ties each account ID to a legal entity and a seller type. Read together with your app-ads.txt, a buyer can verify the chain from your app to us to demand, and a mismatch shows up as a finding on both sides.
Your app-ads.txt
Authorizes skyboosts.com for your account ID at your developer domain. It is the declaration of who may sell; everything else verifies against it.
Our sellers.json
Maps that account ID to the Sky Boosts legal entity and seller type, so the ID in your file resolves to a company a buyer can hold accountable.
Bid request schain
Carries the same IDs on every request, so buyers verify the path at auction time against the live declaration.
We run what we enforce
Dashboard statuses, and what each one means: Verified, the file was fetched, parsed and every line passed; Not found, no file at the resolved domain, and every request for those apps is treated as unauthorized by buyers; Formatted incorrectly, the file exists but records failed structural checks, so parts of your authorization are not being read; Stale, the file no longer matches the networks your apps actually monetize with. Each status carries its last-crawl timestamp, and a re-crawl can be requested the moment you change the file.
Declarations, on request
Our current declarations are available from your account manager, together with the registry entries that back them, for any platform we operate on. Ask for them in your first call and put them through the same validation you would apply to anyone else.
Common questions, answered concretely.
One file per developer domain. Every store listing whose website field points at that domain is covered by the same declaration, so the file lists every authorized system once and the monitor checks every app against it. The account-level view is what makes multi-app drift visible, per app, per store.
Within the crawl cycle: publish the file, trigger a re-crawl from the dashboard, and filtering follows the new declaration. There is no ticket to file and no sync window to wait out, the enforcement reads the crawl, and the crawl reads your domain.
Host the file on any static host under the same domain and make sure the store listing website field resolves to it, what matters is the domain of record, not which server answers. The guide covers the common hosting setups, including the ones that initially look impossible.
DIRECT declares a system you control that sells your inventory directly; RESELLER declares a system authorized to sell it on your behalf through its own relationships. Both are legitimate, the label exists so buyers can see how many parties stand between them and you, and price the path accordingly.
Yes. Buyers cannot know your configuration at crawl time, and a missing file degrades every request for your apps to unauthorized status across the market. The file also protects the inventory you will add next quarter, which nobody can predict today.
If the finding says someone unauthorized is selling your inventory, the escalation path is the incident process on the brand safety page, report, pull, assess, close the loop. If it is a file defect, the finding lands in the dashboard with its fix attached.
Make spoofing someone else's problem.
Turn on crawl monitoring for every app on your account, or read the definitive guide first and bring questions.
Crawl monitoring · error detection · sellers.json cross-check