Key Takeaways

• DSP verification of app inventory is a four-step chain: app store metadata, developer website discovery, app-ads.txt lookup, and sellers.json cross-reference. A failure at any step kills the bid.
• The verification process is more complex than web ads.txt verification. Web verification is two steps (domain to file). App verification adds app store metadata and developer URL resolution as prerequisites.
• Third-party verification vendors augment DSP checks. Companies like Pixalate, DoubleVerify, and IAS crawl app-ads.txt data and provide fraud scoring that buyers use to filter inventory.
• Buyers increasingly use app-ads.txt as part of supply path optimization. Verified direct paths command premium bids. Unverified or reseller paths get deprioritized.
• The crawling infrastructure is big. DSPs and verification vendors maintain crawlers that monitor millions of app store listings, developer websites, and sellers.json files continuously.

---

How Advertisers Validate app-ads.txt Files

From the advertiser's perspective, app-ads.txt is a fraud filter and quality signal rolled into one.

Every time a DSP considers bidding on in-app inventory, it runs a verification process that traces the authorization chain from the app store to the developer's declared sellers list.

Understanding this process from the buyer's side explains why every detail of your app-ads.txt setup matters: the developer URL, the file hosting, the account IDs, and the relationship types. Each one is a checkpoint in a chain that either results in a bid or a rejection.

The Four-Step Verification Chain

Step 1: App Store Metadata Extraction

When a DSP receives a bid request for in-app inventory, the request includes the app's bundle ID (e.g., com.studio.coolgame) and sometimes the app store URL. The DSP needs to find the developer's website.

DSPs and verification vendors maintain crawled databases of app store metadata. They periodically crawl Google Play and the Apple App Store, extracting:

• App bundle IDs
• Developer names
• Developer website URLs
• App store listing URLs

This metadata mapping lets the DSP look up any app's developer website without fetching the app store page in real time during the auction. Which would be way too slow.

If the app store listing doesn't include a developer website URL, the verification chain stops here. No developer URL means no way to find app-ads.txt.

Step 2: Developer Website Resolution

The DSP takes the developer website URL from the app store metadata and constructs the app-ads.txt URL:

text
https://developer-website.com/app-ads.txt

The DSP (or its verification data provider) fetches this URL. Several things can go wrong:

• 404: No file at that path. Verification fails.
• SSL error: Certificate problem. Verification fails.
• Redirect loop or too many hops: Crawler gives up. Verification fails.
• Non-text content type: HTML or other format. Some crawlers reject.
• Timeout: Slow server or CDN. Crawler moves on.

If the fetch succeeds, the DSP has the raw contents of the developer's app-ads.txt file.

Step 3: Seller ID Matching

The DSP now checks whether the SSP from the bid request is authorized. It looks for a line in the app-ads.txt that matches:

• The SSP's exchange domain (e.g., google.com, applovin.com)
• The seller's account ID (the ID reported in the bid request)

If a matching line exists, the DSP notes the relationship type (DIRECT or RESELLER) and the TAG-ID if present.

If no matching line exists, the SSP isn't authorized to sell this app's inventory. Bid rejected.

Step 4: sellers.json Cross-Verification

The most thorough DSPs take one more step. They cross-reference the app-ads.txt entry against the SSP's sellers.json file.

For example, if the app-ads.txt says:

text
applovin.com, 12345, DIRECT

The DSP checks applovin.com/[sellers.json](/library/what-is-sellersjson-and-why-it-matters-for-your-revenue) for seller ID 12345 and verifies:

• seller_type: Should be "PUBLISHER" for DIRECT entries
• domain: Should match the developer's domain
• name: Should match the developer's company name

A mismatch at this level means the authorization claim doesn't hold up. The app-ads.txt says one thing, the SSP's sellers.json says another. The DSP treats this as a verification failure.

How Major DSPs Handle Verification

Google (DV360 and Google Ads)

Google runs one of the most thorough verification systems. Their crawlers index both Google Play and Apple App Store metadata, maintaining a real-time mapping of apps to developer websites. Google enforces app-ads.txt verification as a standard part of their supply quality framework.

With the 2025 AdMob requirement, Google is also verifying from the supply side: apps using AdMob must have a verified app-ads.txt before they can fully serve ads.

The Trade Desk

The Trade Desk integrates app-ads.txt verification into their supply chain quality scoring. Inventory from verified apps receives better quality scores, which influences bid allocation. The Trade Desk also provides transparency tools that let buyers see the verification status of inventory they're purchasing.

Amazon DSP

Amazon's mobile demand uses app-ads.txt verification as part of its quality assessment. Non-verified inventory may still receive some demand but at reduced priority compared to verified sources.

Third-Party Verification Vendors

Beyond DSP-native verification, the advertising ecosystem relies on third-party verification vendors who specialize in supply chain transparency.

Pixalate

Pixalate maintains one of the largest databases of app-ads.txt crawl data. They crawl millions of app store listings and developer websites, providing:

• App-ads.txt adoption statistics
• Verification failure reports
• Fraud risk scoring based on supply chain data

Advertisers use Pixalate data to build pre-bid exclusion lists and monitor supply chain health.

DoubleVerify and IAS

DoubleVerify and Integral Ad Science incorporate app-ads.txt verification into their broader brand safety and fraud prevention platforms. Ads served on unverified inventory get flagged in their reporting, which can trigger advertiser-level blocks.

IAB Tech Lab Transparency Center

The IAB Tech Lab provides aggregated ads/app-ads.txt and sellers.json data through their Transparency Center. This lets platforms and verification vendors access standardized supply chain data for their verification processes.

What Buyers Look For Beyond Basic Verification

Sophisticated buyers go beyond pass/fail verification. They evaluate supply chain quality on a spectrum.

Authorization completeness. What percentage of an app's bid requests come through verified paths? An app where 90% of bid requests are verified scores higher than one where 50% are verified.

Relationship type distribution. What's the ratio of DIRECT to RESELLER entries? Higher DIRECT ratios indicate cleaner, shorter supply paths.

Seller consistency. Are the same sellers consistently authorized, or does the file change erratically? Stable, well-maintained files signal professional ad operations.

Cross-verification success rate. When entries are checked against sellers.json, what percentage pass? High pass rates indicate accurate, well-maintained authorization data.

File freshness. When was the file last updated? A file that hasn't changed in a year for an app that's been adding new ad networks? That signals neglect.

These factors feed into supply chain quality scores that influence how much a DSP is willing to bid. It's not just about whether you have app-ads.txt. It's about how well maintained and accurate it is.

The Crawling Infrastructure

The scale of app-ads.txt verification infrastructure is huge:

• Millions of app store listings crawled across Google Play and Apple App Store
• Hundreds of thousands of developer websites checked for app-ads.txt files
• Thousands of sellers.json files maintained by SSPs, each with tens of thousands of entries
• Crawl cycles running every 24-72 hours to catch updates

DSPs either build this infrastructure in-house or license data from verification vendors. Either way, the investment is real. It reflects how seriously the buy side takes supply chain verification.

What This Means for App Developers

The buyer's verification process reveals why every detail matters.

Your app store developer URL is the entry point. If it's wrong or missing, nothing else matters. The verification chain can't start.

Every ad network needs an entry. Buyers verify per-SSP, not per-app. AppLovin is in your mediation but not in your app-ads.txt? AppLovin bid requests fail verification. Other networks are unaffected. But you lose AppLovin demand.

DIRECT entries get preferential treatment. SPO algorithms prefer shorter paths. You have a direct relationship with an ad network? Label it DIRECT. Labeling it RESELLER costs you premium bid allocation.

Accuracy compounds. A perfectly verified app-ads.txt file sends a strong quality signal. Every verification failure reduces the overall signal. Buyers treat accuracy holistically, not line by line.

Frequently Asked Questions

Do buyers check app-ads.txt for every bid request?

Not in real time during the auction. DSPs maintain cached databases of app-ads.txt data that they update on crawl cycles (24-72 hours). When a bid request arrives, the DSP checks its cached version. The check itself is near-instant.

Can I see which DSPs have verified my app-ads.txt?

Not directly. DSP verification is a buy-side process, and they don't report their verification status to publishers. You can check verification from the supply side through your ad network dashboards (e.g., AdMob's app-ads.txt status) and through supply chain scanning tools like BeamFlow.

What happens if a verification vendor flags my app?

If a vendor like Pixalate or DoubleVerify flags your app as having supply chain issues, advertisers using those vendors may exclude your inventory. The fix is to resolve the app-ads.txt issues (missing file, wrong entries, hosting problems) and wait for the vendor to re-crawl. Typically within a week.

Do verification vendors check differently than DSPs?

The fundamentals are the same: app store metadata > developer URL > app-ads.txt > sellers.json. Verification vendors may have more thorough crawling (checking more apps, more frequently) and may apply extra scoring algorithms. But the underlying data they verify is identical.