Reconcile ads.txt, sellers.json, and SupplyChain IDs When Authorized Inventory Is Rejected

An SSP account is present in the publisher’s ads.txt file and its sellers.json endpoint returns JSON, yet buyers flag the path as unauthorized or opaque. Syntax alone cannot prove the path. The advertising-system domain, seller account ID, DIRECT or RESELLER relationship, sellers.json seller_id, and SupplyChain `asi` and `sid` must describe the same commercial route.

Start with evidence and the smallest reversible change; work on staging when possible, preserve the logs and rollback material if production is already down, and keep the objective specific: audit the publisher declaration, exchange seller record, and OpenRTB SupplyChain nodes as one identifier chain instead of checking three valid-looking files independently.

What the symptom narrows down

• The publisher lists the wrong account ID, relationship type, or canonical advertising-system domain after an account migration or reseller change.
• The exchange’s sellers.json record is missing, confidential in a way the buyer cannot reconcile, or uses a seller type inconsistent with the declared relationship.
• The first SupplyChain node does not match the publisher’s authorized DIRECT record, later nodes are out of order, or the complete flag claims a completeness the nodes do not provide.

The branches are ordered to protect the strongest evidence around this possibility: the publisher lists the wrong account ID, relationship type, or canonical advertising-system domain after an account migration or reseller change. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Programmatic failures cross publisher code, consent and identity modules, wrappers, supply platforms, demand platforms, and the ad server; a blank slot is only the last visible result; auction IDs, request timing, authorization records, and bid status are the evidence that identifies the responsible boundary; in this guide, the practical goal is to audit the publisher declaration, exchange seller record, and OpenRTB SupplyChain nodes as one identifier chain instead of checking three valid-looking files independently.

Evidence to collect before the fix

1. Fetch the canonical publisher /ads.txt without credentials and record redirects, HTTP status, content type, final host, duplicate lines, malformed fields, OWNERDOMAIN, and MANAGERDOMAIN when applicable.
2. For each relevant ads.txt row, fetch https://AD_SYSTEM_DOMAIN/sellers.json and find an exact seller_id match; record seller_type, name/domain disclosure, and whether the system identifies an intermediary.
3. Extract source.ext.schain from one real sanitized bid request and compare each node’s asi and sid in order with the responsible platform’s sellers.json file.
4. Verify the commercial contract with the account owner; a technically well-formed chain cannot establish authorization that the publisher never granted.

The sequence moves from observation toward intervention. Preserve the result of the final check—verify the commercial contract with the account owner; a technically well-formed chain cannot establish authorization that the publisher never granted—because it provides a useful comparison after the repair.

Apply fixes in the safest order

1. Remove stale or unauthorized rows and publish the exact system domain, publisher account ID, and relationship supplied by the contracted platform.
2. Ask the advertising system to correct its sellers.json entry when the authoritative account exists but the public seller record is inconsistent; do not invent a replacement ID locally.
3. Correct SupplyChain construction at the platform that owns the wrong node and retain every paid selling intermediary in order when the chain is marked complete.

Before applying “Remove stale or unauthorized rows and publish the exact system domain, publisher account ID, and relationship supplied by the contracted platform,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can refetch all three public/request artifacts after caches expire and confirm the same case-sensitive identifiers form an unbroken path; a changed symptom at that point is new evidence, not permission to make several more changes at once.

curl -fsSIL https://PUBLISHER.example/ads.txt
curl -fsS https://PUBLISHER.example/ads.txt | \
  awk -F',' '$1 ~ /AD_SYSTEM.example/ {gsub(/^[ \t]+|[ \t]+$/,"",$2); print $0}'

curl -fsS https://AD_SYSTEM.example/sellers.json | \
  jq --arg sid 'SELLER_ACCOUNT_ID' \
     '.sellers[] | select(.seller_id == $sid) |
      {seller_id, seller_type, name, domain, is_confidential}'

Prove recovery

• Refetch all three public/request artifacts after caches expire and confirm the same case-sensitive identifiers form an unbroken path.
• Run the path through the IAB Tech Lab transparency tooling or the buyer’s validation report and preserve the dated result.
• Monitor authorized-request and spend recovery by supply path without adding unrelated reseller rows merely to improve coverage.

One successful refresh is not closure. Keep the incident open until you can also run the path through the IAB Tech Lab transparency tooling or the buyer’s validation report and preserve the dated result, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

A useful monetization escalation includes the page and ad unit, UTC time, auction and transaction IDs, geography and device, consent state, configured timeout, sanitized OpenRTB fragment, bidder events, and the exact ad-server targeting produced; remove user identifiers, cookies, IP addresses, and commercial credentials before sharing; include the result of this first observation: fetch the canonical publisher /ads.txt without credentials and record redirects, HTTP status, content type, final host, duplicate lines, malformed fields, OWNERDOMAIN, and MANAGERDOMAIN when applicable.

State what was tested, including the result of “Fetch the canonical publisher `/ads.txt` without credentials and record redirects, HTTP status, content type, final host, duplicate lines, malformed fields, OWNERDOMAIN, and MANAGERDOMAIN when applicable,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

Shortcuts that create a second incident

• Do not copy a competitor’s ads.txt file or bulk-add reseller lines from an unverified list; every row is a public authorization claim.
• Do not treat sellers.json is_confidential as permission to omit the seller object or fabricate a public identity.

Primary references

• IAB Tech Lab ads.txt 1.1 implementation guide — official reference consulted for this guide.
• IAB Tech Lab sellers.json and SupplyChain — official reference consulted for this guide.
• IAB Tech Lab SupplyChain FAQ — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Remove stale or unauthorized rows and publish the exact system domain, publisher account ID, and relationship supplied by the contracted platform”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.