Common sellers.json Mismatches Explained

Key Takeaways

• sellers.json mismatches are the hidden failures that syntax-only validation misses. Your ads.txt file can be perfectly formatted and still fail verification because the SSP's data tells a different story.
• Relationship type conflicts are the most impactful mismatch. Claiming DIRECT when sellers.json says INTERMEDIARY causes hard verification failures.
• Domain mismatches affect DIRECT entries most severely. DSPs expect the domain in sellers.json to match the publisher's actual domain for DIRECT relationships.
• SSPs create mismatches without telling you. Account reclassifications, domain field updates, and data cleanup on the SSP's end can break previously working entries.
• 24% of ads.txt entries have some form of sellers.json mismatch. Based on BeamFlow's cross-verification of 120K+ publisher domains.

Common sellers.json Mismatches Explained

A sellers.json mismatch happens when the information in your ads.txt does not align with what the SSP reports in their sellers.json file. Your ads.txt makes a claim. The SSP's sellers.json either confirms it or contradicts it. When it contradicts, the DSP sees a conflict and either rejects the bid or downgrades the supply path.

These mismatches are particularly frustrating because they are invisible to publishers who only validate ads.txt syntax. The file looks correct. The format is right. The account IDs appear valid. But the cross-verification against sellers.json reveals problems that have been silently costing bids.

Here are the mismatches we see most frequently across the ecosystem.

Mismatch 1: Relationship Type Conflict

What it looks like:

• ads.txt: ssp-x.com, 12345, DIRECT
• sellers.json: seller_type: "INTERMEDIARY"

Why it happens: The publisher listed the entry as DIRECT, believing they hold the account directly. But the SSP classifies the account as belonging to an intermediary. Common when a monetization partner set up the SSP account on the publisher's behalf, or when the SSP reclassified the account type after an internal review.

Impact: Hard verification failure. The publisher claims one thing, the SSP reports another. DSPs that enforce strict verification reject the bid outright.

Fix: Determine who actually holds the account. If a partner holds it, change your ads.txt to RESELLER. If you hold it directly, contact the SSP to correct their sellers.json entry.

Mismatch 2: Domain Mismatch

What it looks like:

• ads.txt hosted on: publisher.com
• sellers.json: domain: "old-publisher-domain.com"

Why it happens:

• Publisher rebranded or changed domains but the SSP still has the old domain on file
• SSP entered the wrong domain during account setup
• The seller entry belongs to a parent company with a corporate domain, not the publishing domain
• Publisher uses multiple domains and the SSP has a different one on file

Impact: For DIRECT entries, DSPs expect the domain to match the publisher's actual domain. A mismatch means the DSP cannot confirm that the publisher owns this account. Verification degrades.

Fix: Contact the SSP and request a domain update in their sellers.json entry. Provide your current, active publishing domain.

Mismatch 3: ID Not Found (Missing Entry)

What it looks like:

• ads.txt: ssp-x.com, 12345, DIRECT
• sellers.json: No entry with seller_id "12345"

Why it happens:

• Wrong account ID in ads.txt (most common)
• New account not yet added to sellers.json
• SSP migrated platforms and ID format changed
• SSP removed the entry during a cleanup

Impact: Complete verification failure. The DSP cannot find any information about the seller. Bids rejected.

Fix: Verify the correct account ID from the SSP dashboard. If the ID is correct, contact the SSP about adding your entry to sellers.json.

Mismatch 4: Confidential Entry

What it looks like:

• ads.txt: ssp-x.com, 12345, DIRECT
• sellers.json: seller_id: "12345", is_confidential: 1 (no name, domain, or seller_type visible)

Why it happens: The SSP marked your entry as confidential, hiding your identity from public view. This can be an SSP default, a business relationship restriction, or an oversight.

Impact: DSPs find the seller_id but cannot verify the name, domain, or seller_type. Verification is incomplete. SPO algorithms may deprioritize the path. Some DSPs may skip inventory from confidential sellers entirely.

Fix: Contact the SSP and request that your entry be marked as non-confidential. The transparency benefits (higher verification scores, better buyer confidence) almost always outweigh any confidentiality concerns.

Mismatch 5: Name Mismatch

What it looks like:

• Your company: "Publisher Media Group"
• sellers.json: name: "Old Company Name Inc."

Why it happens: Company renamed, was acquired, or the SSP has an outdated business name on file. Less impactful than seller_type or domain mismatches because most DSPs do not strictly verify the name field. But inconsistent naming across SSPs reduces trust signals.

Impact: Generally low. Most DSPs prioritize seller_type and domain verification over name matching. But it is a sign that the SSP's data may be stale overall.

Fix: Contact the SSP and update your business name in their system.

Mismatch 6: TAG-ID Discrepancy

What it looks like:

• ads.txt: ssp-x.com, 12345, DIRECT, f08c47fec0942fa0
• SSP's actual TAG certification ID: different from f08c47fec0942fa0

Why it happens: The TAG-ID (fourth field) should be the SSP's Trustworthy Accountability Group certification ID. It is the same for all entries referencing that SSP. If you copied the wrong TAG-ID, it may not match the SSP's actual certification.

Impact: Moderate. TAG-IDs are a secondary verification point. A wrong TAG-ID does not cause as severe a failure as a wrong seller_id or seller_type, but it reduces verification confidence.

Fix: Find the correct TAG-ID from the SSP's official ads.txt entry template. The TAG-ID is per-SSP, not per-publisher.

Mismatch 7: BOTH vs PUBLISHER/INTERMEDIARY

What it looks like:

• ads.txt: ssp-x.com, 12345, DIRECT
• sellers.json: seller_type: "BOTH"

Why it happens: The SSP classifies the account as operating in both a publisher and intermediary capacity under the same seller_id. The BOTH type is a catch-all that signals the account handles both direct and resold inventory.

Impact: Low to moderate. BOTH is technically compatible with both DIRECT and RESELLER in ads.txt. Most DSPs accept this alignment. However, The Trade Desk recommends that sellers split publisher and intermediary inventory into separate IDs rather than using BOTH.

Fix: Generally no action needed if BOTH is the SSP's chosen classification. If you want cleaner verification, ask the SSP if they can assign separate seller_ids for publisher and intermediary roles.

Why SSPs Create Mismatches

Publishers often assume sellers.json mismatches are their fault. Sometimes they are (wrong ID, wrong relationship type in ads.txt). But frequently, the SSP created the mismatch:

• Account reclassification. SSP audits their seller database and changes your seller_type without notification.
• Domain field updates. SSP updates the domain field based on their internal records, which may not match your current domain.
• Platform migration. SSP merges systems and your seller data gets transformed in unexpected ways.
• Batch data processing. SSP runs automated processes that inadvertently modify seller entries.

The key insight: you cannot prevent SSP-side changes. You can only monitor for them and respond quickly.

Monitoring for Mismatches

One-time validation is not enough because SSPs change their data continuously.

Quarterly manual audit: For publishers with fewer than 20 entries, manually cross-reference each entry against the SSP's sellers.json.

Automated continuous monitoring: For publishers with larger files or those who want real-time alerting, use BeamFlow to continuously monitor your ads.txt entries against live sellers.json data across all SSPs.

SSP relationship management: Maintain communication with your SSP account managers. When you notice a mismatch, contact them immediately. Document the issue and the requested fix.

Frequently Asked Questions

Which mismatch type is most common?

ID Not Found (missing entry) is the most frequent, followed by relationship type conflicts. Domain mismatches are third.

Can one mismatch affect other entries?

No, each entry is verified independently. A mismatch on one SSP line does not affect verification of other SSP lines. But if multiple lines for the same SSP all reference the same wrong ID, they all fail.

Do mismatches ever resolve themselves?

Sometimes. If the SSP updates their sellers.json to correct data, the mismatch resolves on the next DSP crawl cycle. But this requires the SSP to take action. Do not assume self-resolution.

How do I prioritize which mismatches to fix first?

Fix relationship type mismatches first (highest impact on verification). Then domain mismatches. Then missing entries. Confidential flags and name mismatches are lower priority but still worth addressing.