Trace one authorized sale from your domain to the final bid request

Start with a relationship, not a file-size target

Export the current ads.txt file from the public root of the domain and compare it with a publisher-owned register. Each data row should have an advertising-system domain, seller account identifier, and relationship type; a certification identifier may also appear. A syntactically valid row can still be wrong. Confirm that the named account is yours or belongs to the intermediary you intentionally authorized, and record the contract or partner ticket that supports it.

DIRECT means the publisher controls the indicated account with that advertising system. RESELLER means another entity controls that account and is authorized to resell the inventory. It does not mean that one route is morally better, nor does it describe every later hop. If a partner supplies ten rows, ask what each account and system does. Remove a row only after confirming that the relationship ended; an unexplained cleanup can cut off legitimate demand.

The example domains and identifiers are illustrative.

Source notes: Ads.txt 1.1 specification

Cross the row into sellers.json

Fetch sellers.json from the advertising-system domain named in the row. Find an exact seller_id match. Compare the seller type and disclosed identity with the commercial relationship you understand. A PUBLISHER entry describes an entity that owns and directly controls the monetized inventory; an INTERMEDIARY entry describes an entity that does not. A confidential name is not automatically an error, but the identifier and seller type still need to match the path you were sold.

Classify the result as matched, missing, conflicting, or unresolved. Missing means the account identifier does not appear. Conflicting means, for example, your direct publisher account is represented as an intermediary. Unresolved covers inaccessible files, malformed JSON, and identity that cannot be connected to the contracting party. Send the smallest reproducible record to the partner: your ads.txt row, the sellers.json URL, the seller_id searched, the observed entry, and retrieval time.

Source notes: Sellers.json specification

Treat schain as transaction evidence

The SupplyChain object belongs to a bid request, so it cannot be proven by inspecting two public files. Ask the partner for a captured test request or use an authorized diagnostic view. In a complete chain, the first node represents the initial advertising system and seller involved with the inventory owner; the last represents the entity sending the bid request. Each node identifies an advertising system and seller account. The complete flag says whether all payment-path nodes are represented, not whether the traffic is valid or the campaign performed.

Compare the first applicable node with the ads.txt authorization and compare every node with the corresponding system's sellers.json. Stop at the boundary of your evidence. A publisher can verify its public file and the records exposed by partners, but usually cannot independently certify every downstream transformation. Record an incomplete chain as incomplete. Do not repair it by guessing a missing node.

Source notes: OpenRTB SupplyChain object

Run one path before auditing the whole file

Illustrative audit: a site has 42 ads.txt rows. Select the five rows responsible for current spend rather than reviewing all 42 as one undifferentiated list. Row A names exchange.example, account 2048, DIRECT. The matching sellers.json entry exists but says INTERMEDIARY. A test request begins with exchange.example and 2048, then names a second system, and marks the chain complete. The public authorization and transaction identifier align, while the seller type conflicts. The correct action is a partner clarification, not silently changing DIRECT to RESELLER.

Keep one row per finding with severity, owner, evidence link, and next check. Block launch for an account identifier that no partner recognizes or a route that was never authorized. Queue ordinary naming ambiguity for written resolution. Recheck after contract changes, platform migrations, domain transfers, or partner offboarding. The useful output is a traceable authorization graph, not a score based on how many lines the file contains.

• Fetch the live root file; do not audit a dashboard copy alone.
• Match the seller identifier exactly across files and requests.
• Separate a syntax error from a commercial-relationship conflict.
• Save the before-and-after files when a partner resolves an issue.

Source notes: Ads.txt 1.1 specification · Sellers.json specification · OpenRTB SupplyChain object