Decoding ads.txt 1.1, app-ads.txt, and sellers.json: OWNERDOMAIN, MANAGERDOMAIN, and Open Bidding Direct Pay

When a tier-1 DSP receives an OpenRTB 2.6 bid request containing a source.schain object, its pre-bid supply path evaluator executes a three-way cryptographic and lexical lookup in under two milliseconds. The bidder cross-references the supply chain node's asi (advertising system identifier) and sid (seller ID) against two external cached registries: the publisher's root-level ads.txt or app-ads.txt file, and the exchange's sellers.json index. If the relationship declarations across those three artifacts fail to align, the DSP either throttles queries per second (QPS) to that supply path, applies a steep bid-shading penalty to offset perceived intermediary risk, or drops the bid request prior to auction evaluation.

For years, AdOps teams treated ads.txt and app-ads.txt as static append-only text files, pasting blocks of partner lines without auditing how those lines resolved against upstream sellers.json files. That operational model now causes measurable yield loss. Multi-domain media holding companies, Google Multiple Customer Management (MCM) structures, and Connected TV (CTV) inventory-sharing arrangements routinely break legacy validation checks when the corporate entity listed in an SSP's sellers.json does not match the consumer-facing domain in the bid request.

Resolving these discrepancies requires implementing the IAB Tech Lab Ads.txt v1.1 directives (OWNERDOMAIN and MANAGERDOMAIN) alongside newly updated settlement classifications such as Google Open Bidding Direct Pay. At Sky Boosts, where we operate a unified SSP and monetization platform across Mobile App, CTV, and Web inventory on reliable Net-30 and Net-60 payment terms, engineering clean, single-hop supply paths across 100% Google-friendly and HUMAN / Pixalate IVT-clean inventory is foundational to maximizing bid density and clearing prices.

How DSPs Traverse the app-ads.txt and sellers.json Graph

Programmatic supply chain verification operates as a directed graph where every edge must be mutually attested by both the publisher and the monetizing exchange. The verification cycle relies on three distinct data structures that must remain in strict parity:

The Publisher Declaration (ads.txt / app-ads.txt): Hosted at the root of the publisher's web domain or the developer_url extracted from the Google Play Store or Apple App Store metadata. Each record contains four comma-separated fields: the canonical exchange domain, the publisher's account ID (seller_id), the account relationship type (DIRECT or RESELLER), and the optional certification authority ID (TAG-ID).
The Real-Time Bid Stream (source.schain): Injected into the OpenRTB bid request by each participating SSP. The nodes array records every entity that participates in the financial settlement of the impression, ordered chronologically from the origin publisher node to the final exchange transmitting the request to the DSP.
The Exchange Registry (sellers.json): Hosted by the SSP at https://{exchange_domain}/sellers.json. As defined by the IAB Tech Lab sellers.json specification, sellers.json is published by SSPs and exchanges to map seller_id values found in ads.txt and the OpenRTB SupplyChain object to legal entity names, business domains, and seller_type (PUBLISHER, INTERMEDIARY, or BOTH).

When an SSP sends a bid request, the DSP validates the first node in the schain.nodes array against the publisher's ads.txt or app-ads.txt file, and then validates that same sid against the SSP's sellers.json payload:

{
  "openrtb_source_schain": {
    "complete": 1,
    "ver": "1.0",
    "nodes": [
      {
        "asi": "skyboosts.com",
        "sid": "pub-99402",
        "hp": 1,
        "rid": "req-8839201-a"
      }
    ]
  },
  "ssp_sellers_json_entry": {
    "seller_id": "pub-99402",
    "name": "Apex Digital Media LLC",
    "domain": "apexmedia.com",
    "seller_type": "PUBLISHER",
    "is_passthrough": 0
  }
}

If the publisher's domain is apexmedia.com and its ads.txt file contains skyboosts.com, pub-99402, DIRECT, the three-way handshake succeeds. However, if Apex Digital Media LLC owns twenty consumer web properties and thirty mobile apps under distinct domains (for example, dailygamingnews.com), a naive DSP crawler comparing site.domain (dailygamingnews.com) against the sellers.json domain field (apexmedia.com) registers a domain mismatch. AdOps teams can diagnose these exact graph breaks before they impact revenue by auditing the registry entries behind every account ID.

Implementing Ads.txt v1.1: OWNERDOMAIN and MANAGERDOMAIN Declarations

To eliminate false-positive domain mismatches across corporate portfolios and managed monetization networks, the IAB Tech Lab Ads.txt and App-Ads.txt v1.1 specifications introduce the OWNERDOMAIN and MANAGERDOMAIN variables (building on the v1.0.3 INVENTORYDOMAIN directive) to clarify ownership and primary monetization management in sellers.json supply chain validation.

Each variable serves a distinct architectural function within the validation graph:

OWNERDOMAIN: Declares the root business domain of the corporate legal entity that owns the web property or mobile application being crawled. A file may contain only a single OWNERDOMAIN declaration. When present, DSPs match the OWNERDOMAIN value directly against the domain attribute of the PUBLISHER entry in the SSP's sellers.json file. If dailygamingnews.com/ads.txt declares OWNERDOMAIN=apexmedia.com, every SSP sellers.json file can maintain a single consolidated seller_id listing domain: "apexmedia.com", and all properties under that corporate umbrella validate cleanly.
MANAGERDOMAIN: Declares the root domain of an external monetization platform or MCM parent partner that manages ad operations and yield exclusively (or for a designated geographic market) on behalf of the publisher. Unlike OWNERDOMAIN, an ads.txt or app-ads.txt file can specify multiple MANAGERDOMAIN variables, appended with an optional three-letter ISO 3166-1 alpha-3 country code to denote regional exclusivity. When a publisher delegates monetization through GAM MCM (Manage Inventory) or our unified SSP and monetization platform, declaring MANAGERDOMAIN signals to DSPs why the primary monetizing seat appears in the supply chain.
INVENTORYDOMAIN: Introduced in v1.0.3 specifically for CTV and OTT environments where content programmers, studio networks, and virtual MVPD platform operators co-monetize an ad pod through Server-Side Ad Insertion (SSAI). When a CTV app publisher delegates specific ad slots to a channel owner, INVENTORYDOMAIN instructs the DSP crawler to fetch and merge the authorized seller records hosted at https://{inventory_domain}/app-ads.txt.

A properly structured v1.1 file integrates these directives at the header level alongside standard authorization records:

# Ads.txt v1.1 Configuration for Multi-Property Publisher
CONTACT=adops@dailygamingnews.com
OWNERDOMAIN=apexmedia.com
MANAGERDOMAIN=skyboosts.com
MANAGERDOMAIN=eu-partner-network.com, GBR

# Direct Monetization Seats (Owner & Primary Manager)
google.com, pub-4829103847561029, DIRECT, f08c47fec0942fa0
skyboosts.com, pub-99402, DIRECT

# Curated Reseller Demand Paths (Strictly Scoped)
google.com, pub-7719283746501928, RESELLER, f08c47fec0942fa0

For engineering teams managing dozens of domains or mobile storefronts, consult our definitive app-ads.txt guide for full specification edge cases, including subdomain inheritance rules and cache-control header requirements.

DIRECT vs. RESELLER Designations: Supply Path Optimization (SPO) Mathematics

Buy-side Supply Path Optimization (SPO) algorithms evaluate more than simple authorization; they calculate path efficiency and fee transparency. Every node in an OpenRTB schain array with hp: 1 (indicating that the entity is involved in the flow of payment) represents a potential margin extraction point between the advertiser's gross spend and the publisher's net payout.

When evaluating ads.txt and sellers.json pairs, tier-1 DSPs classify supply routes into a strict verification matrix:

Publisher `ads.txt` Type	SSP `sellers.json` Type	`schain` Hop Count	DSP SPO Evaluation & Bidding Behavior
`DIRECT`	`PUBLISHER`	1 Hop (`hp: 1`)	Optimal Direct Path: Full bid density, zero multi-hop shading penalty, priority QPS allocation.
`RESELLER`	`INTERMEDIARY` or `BOTH`	2+ Hops (`hp: 1`)	Validated Resold Path: Deprioritized if a parallel 1-hop `DIRECT` path exists for the same auction.
`DIRECT`	`INTERMEDIARY`	Any	Graph Contradiction: Flagged as unauthorized `DIRECT` spoofing unless linked via `MANAGERDOMAIN`.
`RESELLER`	`PUBLISHER`	1 Hop (`hp: 1`)	Suboptimal Configuration: Validated, but publisher forfeits `DIRECT` buyer campaign filters.

The mathematical impact on yield is driven by DSP auction deduplication and bid shading. Many brand-safe PMP deals and automated DSP buying strategies apply a strict pre-bid filter: schain.nodes.length === 1 && relationship === 'DIRECT'. If a publisher lists forty RESELLER lines in its ads.txt file for the same exchange, the DSP receives duplicate bid requests for the exact same impression opportunity across multiple seller IDs. To conserve compute infrastructure, the DSP's QPS shaper throttles the reseller seats and routes bids exclusively through the verified DIRECT / PUBLISHER seat.

Furthermore, maintaining bloated RESELLER lists exposes inventory to clearing price cannibalization. When a secondary intermediary runs an upstream auction and forwards requests with a lower or inconsistent floor price, DSP bid-shading algorithms calibrate down toward the lowest observed clearing price for that domain or bundle ID. Implementing automated app-ads.txt management allows publisher AdOps teams to prune dormant RESELLER lines and enforce strict parity between active Prebid / GAM line items and published authorization records.

How Google Open Bidding Direct Pay Changes ads.txt and sellers.json Classifications

One of the most consequential architectural shifts in programmatic supply chain mapping is Google Open Bidding Direct Pay. Historically, under the standard Google Open Bidding (formerly EBDA) settlement model, Google Ad Manager acted as the central financial clearinghouse for all participating third-party exchanges. Even when a publisher held an existing business relationship with a participating SSP, Google collected payment from the Open Bidding partner and remitted the consolidated payout to the publisher. Because Google sat in the payment flow (hp: 1) between the SSP and the publisher, the participating SSP was required to list that account as INTERMEDIARY (or BOTH) in its sellers.json file, and the publisher had to declare the SSP's seat as RESELLER in ads.txt and app-ads.txt.

That legacy classification created a structural disadvantage inside GAM 360 unified auctions: server-to-server demand flowing through Open Bidding appeared to DSPs as a 2-hop resold path (INTERMEDIARY / RESELLER), whereas the exact same SSP integrated via client-side Prebid.js or Prebid Mobile appeared as a 1-hop direct path (PUBLISHER / DIRECT). Under Google Open Bidding Direct Pay, publishers contract and get paid directly by participating SSPs; the SSP lists the inventory as PUBLISHER in sellers.json (rather than INTERMEDIARY) and the publisher lists the SSP as DIRECT in ads.txt and app-ads.txt.

Cryptographic verification diagram linking an App Store bundle, an app-ads.txt file with MANAGERDOMAIN, and a sellers.json database into a verified green padlock.

By decoupling auction orchestration from financial clearing, Open Bidding Direct Pay restores single-hop supply chain parity to GAM server-to-server bidding. Google Ad Manager still executes the real-time unified first-price auction and transmits the OpenRTB callout to the participating exchange, but because Google does not take possession of the funds for that transaction (hp: 0 from a clearing intermediary standpoint), the participating SSP becomes the first and only payment node (hp: 1) in the SupplyChain object. For publishers monetizing through Sky Boosts, combining direct contractual settlement on Net-30 and Net-60 terms with a clean DIRECT / PUBLISHER classification ensures that server-side Open Bidding impressions qualify for DSP direct-only campaign budgets.

Transitioning Participating OB Partners from INTERMEDIARY to PUBLISHER

Migrating an active Open Bidding yield partner to Direct Pay requires a synchronized cutover between the publisher's ads.txt / app-ads.txt file and the SSP's sellers.json publication pipeline. Executing these edits out of sequence triggers temporary graph contradictions that can suppress DSP bidding for 24 to 72 hours while crawlers refresh their caches.

AdOps engineers should follow a strict three-phase cutover protocol:

Pre-Cutover Dual Declaration (If changing seller_id): If the participating SSP assigns a new dedicated seller_id for Direct Pay settlement, the SSP first publishes the new seller_id in its sellers.json file with seller_type: "PUBLISHER" and domain matching the publisher's OWNERDOMAIN. Simultaneously, the publisher appends the new DIRECT line to ads.txt and app-ads.txt while keeping the legacy RESELLER line intact for 72 hours until GAM traffic fully cuts over.
In-Place Seat Reclassification: If the SSP retains the existing seller_id and transitions it in-place when the Direct Pay contract is countersigned in GAM, the SSP must update its sellers.json entry from INTERMEDIARY to PUBLISHER (or temporarily BOTH during the transition window) on the exact day the publisher updates the corresponding ads.txt line from RESELLER to DIRECT. Never flip an ads.txt line from RESELLER to DIRECT while the upstream sellers.json record still reads INTERMEDIARY, as strict DSP SPO filters penalize DIRECT + INTERMEDIARY mismatches much more severely than RESELLER + PUBLISHER states.
GAM Yield Group Verification: Once the Direct Pay agreement is active inside Google Ad Manager and both external files have been recrawled, verify in the outbound OpenRTB bid stream inspector that the source.schain object contains a single payment hop (hp: 1) mapping to the direct seat.

Auditing Bundle ID Mismatches Across Google Play and Apple App Store

While web ads.txt resolution relies on a straightforward HTTPS lookup against the bid request's site.domain, mobile and CTV app-ads.txt resolution requires a multi-step metadata extraction pipeline across third-party app storefronts. According to the IAB Tech Lab app-ads.txt specification, DSP crawlers do not use the app.domain field passed in the OpenRTB bid request as the authoritative lookup root, because app.domain can be arbitrarily set in the client SDK configuration. Instead, DSPs use app.bundle and app.storeurl to query the official app store listing, scrape the verified developer website URL (developer_url), translate that URL into a canonical root domain, and fetch https://{developer_domain}/app-ads.txt.

In production Mobile App and CTV environments, three recurring engineering defects routinely break this store-to-domain resolution chain:

iOS and tvOS Alphanumeric Bundle ID vs. Numeric trackId Collisions: On Google Play, the store identifier and the application package name are identical (for example, com.apexmedia.solitaire). On Apple iOS and tvOS, however, the internal Xcode bundle identifier is an alphanumeric reverse-DNS string (com.apexmedia.solitaire), whereas the public App Store identifier is a numeric trackId (for example, 1492837465). OpenRTB 2.6 guidelines and major DSP crawlers require app.bundle on iOS and tvOS to pass the numeric Apple Store ID so the crawler can query the iTunes Lookup API (https://itunes.apple.com/lookup?id=1492837465) to retrieve the sellerUrl. Passing the reverse-DNS string on iOS without a valid app.storeurl causes store metadata lookups to fail, marking the inventory as unverified.
Subdomain and Redirect Chain Failures: The IAB specification permits crawlers to follow at most one HTTP redirect outside the original root domain only under strict conditions, and establishes a strict subdomain fallback order (for example, if the store listing URL is https://games.support.apexmedia.com/contact, the crawler strips the path, checks https://games.support.apexmedia.com/app-ads.txt, and if not found, falls back directly to the first-level subdomain https://support.apexmedia.com/app-ads.txt and then the root https://apexmedia.com/app-ads.txt). If a publisher sets their App Store Marketing URL to a third-party link shortener, a social media page, or an HTTP endpoint that chains multiple 302 redirects across domains, DSP crawlers abort the lookup.
CDN Bot-Mitigation Challenges on /app-ads.txt: Publishers frequently place corporate marketing websites behind strict CDN Web Application Firewalls (WAF) configured with JavaScript challenges or CAPTCHA verification for non-browser user agents. Because DSP app-ads.txt crawlers operate as headless automated fetchers expecting a 200 OK status with a Content-Type: text/plain response header, WAF rules that return a 403 Forbidden or a 200 OK HTML challenge page wipe out programmatic authorization across all connected SSPs within 48 hours.

Before deploying a new app release or modifying store metadata, mobile and CTV engineering teams should validate their store listing resolution and OWNERDOMAIN syntax using the checklist in the definitive app-ads.txt guide. By enforcing explicit WAF allow-rules for the /ads.txt and /app-ads.txt paths, declaring accurate v1.1 OWNERDOMAIN and MANAGERDOMAIN headers, and aligning DIRECT declarations with PUBLISHER seats under Google Open Bidding Direct Pay and Sky Boosts direct integrations, publishers eliminate supply-path friction and capture the full clearing value of their inventory.