Key Takeaways

• ads.txt and sellers.json are two halves of the same verification system. ads.txt is the publisher's side (who I authorize). sellers.json is the SSP's side (who this seller actually is).
• DSPs check both files to verify every bid request. A passing ads.txt check with a failing sellers.json check still results in a rejected bid.
• The seller_id is the link between the two files. The account ID in your ads.txt entry must match a seller_id in the SSP's sellers.json. Same number, same meaning.
• Relationship types must align across both files. DIRECT in ads.txt should correspond to PUBLISHER in sellers.json. RESELLER in ads.txt should correspond to INTERMEDIARY in sellers.json.
• Neither file is sufficient alone. ads.txt without sellers.json means the DSP knows who is authorized but can't confirm their identity. sellers.json without ads.txt means the DSP knows the seller's identity but not whether the publisher authorized them.

---

How sellers.json Works With ads.txt

Your ads.txt file makes a claim. The SSP's sellers.json file either backs it up or contradicts it. The DSP checks both and decides whether to bid.

This two-sided verification is the foundation of programmatic supply chain transparency. The IAB Tech Lab designed these standards to work together, with ads.txt providing publisher-side authorization and sellers.json providing sell-side identity confirmation. Neither file was intended to function in isolation.

Understanding how they connect helps publishers see why an ads.txt entry that looks correct can still fail verification. And why monitoring sellers.json isn't optional.

The Connection: seller_id

The field that links ads.txt to sellers.json is the account ID (second field in ads.txt), which maps to the seller_id field in sellers.json.

In your ads.txt:

text
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0

The pub-1234567890123456 is your account ID on Google's platform.

In Google's sellers.json:

json
{
  "seller_id": "pub-1234567890123456",
  "name": "Your Company Name",
  "domain": "yourdomain.com",
  "seller_type": "PUBLISHER"
}

The seller_id is the same string: pub-1234567890123456. This is how the DSP connects your authorization claim to the SSP's identity record. Same number in both files, different perspectives on the same relationship.

How DSPs Use Both Files Together

When a DSP receives a bid request, the verification process checks both files in sequence.

Publisher Side (ads.txt)

1. DSP extracts the publisher domain from the bid request
2. DSP fetches publisher-domain.com/ads.txt
3. DSP looks for a line matching the SSP and seller ID from the bid request
4. If found, notes the relationship type (DIRECT or RESELLER) and TAG-ID

This answers: "Did the publisher authorize this seller?"

SSP Side (sellers.json)

1. DSP fetches ssp-domain.com/sellers.json
2. DSP looks for the seller_id that matches the account ID from the bid request
3. If found, extracts: name, domain, seller_type

This answers: "Who is this seller, and what's their relationship with the SSP?"

Cross-Verification

1. DSP compares the two:

- Does ads.txt DIRECT match sellers.json PUBLISHER? (Or does RESELLER match INTERMEDIARY?)

- Does the sellers.json domain match the publisher domain from the bid request?

- Does the seller entry exist and is it non-confidential?

If all checks pass: bid proceeds at full confidence.

If any check fails: bid rejected or downgraded.

How Relationship Types Map Between Files

The relationship type terminology differs between the two files, but they describe the same thing.

| ads.txt | sellers.json | Meaning |

|---------|-------------|---------|

| DIRECT | PUBLISHER | The publisher owns the account and receives payment directly from the SSP |

| RESELLER | INTERMEDIARY | An intermediary holds the account and resells the publisher's inventory |

| (either) | BOTH | The entity operates as both publisher and intermediary under the same account |

The alignment must hold. If your ads.txt says DIRECT for account 12345 but the SSP's sellers.json shows account 12345 as INTERMEDIARY, the verification breaks. The publisher claims a direct relationship, but the SSP says the account holder is an intermediary. The DSP can't reconcile these two claims.

What Each File Cannot Do Alone

ads.txt Without sellers.json

If a DSP only checks ads.txt, it knows the publisher authorized a specific seller on a specific SSP. But it doesn't know:

• Whether the seller is a real entity or a fabricated entry
• Whether the seller's domain matches the publisher's domain
• Whether the relationship type claimed in ads.txt is accurate

Without sellers.json, ads.txt is a self-reported claim with no external confirmation. A fraudster who compromises a publisher's server could add any entry to ads.txt, and without sellers.json to cross-reference, the DSP has limited ability to detect the manipulation.

sellers.json Without ads.txt

If a DSP only checks sellers.json, it knows the identity of the seller making the bid request. But it doesn't know:

• Whether the publisher actually authorized this seller
• Whether the publisher is even aware their inventory is being sold through this path
• Whether the specific domain in the bid request has approved the transaction

Without ads.txt, sellers.json confirms identity but not authorization. A legitimate SSP seller could still be selling unauthorized inventory (spoofing a publisher domain) without the publisher's knowledge.

Together: The Full Picture

When both files align, the DSP has:

• Publisher authorization (ads.txt): "This seller is approved"
• Seller identity (sellers.json): "This seller is who they claim to be"
• Relationship consistency: "Both parties agree on the nature of the relationship"
• Domain confirmation: "The claimed domain matches across both files"

This two-sided verification is what gives DSPs the confidence to bid at full competitive value.

Common Misalignment Scenarios

Scenario 1: Account ID Not Found in sellers.json

Your ads.txt has: ssp-x.com, 12345, DIRECT

The DSP checks ssp-x.com's sellers.json and finds no entry for seller_id 12345.

What happened: Either the account ID in your ads.txt is wrong, or the SSP hasn't added your account to their sellers.json yet. Common with newer accounts or after platform migrations.

Impact: Complete verification failure for that line. DSPs can't confirm the seller's identity.

Fix: Verify your account ID with the SSP. If it's correct, ask the SSP when your account will appear in their sellers.json.

Scenario 2: Relationship Type Mismatch

Your ads.txt has: ssp-x.com, 12345, DIRECT

sellers.json shows: seller_id: "12345", seller_type: "INTERMEDIARY"

What happened: You claim a direct relationship. The SSP classifies the account as an intermediary. This can happen when a monetization partner set up the SSP account on your behalf.

Impact: DSPs see the conflict. Strict verifiers reject the bid. Others downgrade confidence.

Fix: Either update your ads.txt to say RESELLER (if the account truly is held by an intermediary) or contact the SSP to correct the seller_type in their sellers.json (if you truly hold the account directly).

Scenario 3: Domain Mismatch

Your ads.txt has: ssp-x.com, 12345, DIRECT

sellers.json shows: seller_id: "12345", domain: "old-domain.com"

What happened: You rebranded or changed domains. Your SSP still has the old domain in their sellers.json.

Impact: The DSP sees the bid request comes from new-domain.com but sellers.json says the account belongs to old-domain.com. Mismatch. Verification may fail.

Fix: Contact the SSP and request they update the domain field in your sellers.json entry.

Scenario 4: Confidential Entry

Your ads.txt has: ssp-x.com, 12345, DIRECT

sellers.json shows: seller_id: "12345", is_confidential: 1

What happened: The SSP marked your account as confidential. Your identity is hidden.

Impact: The DSP finds the seller_id but can't verify the name, domain, or seller_type. Verification is incomplete. SPO algorithms may deprioritize the path.

Fix: Ask the SSP to mark your entry as non-confidential.

The SupplyChain Object: The Third Piece

While ads.txt and sellers.json handle authorization and identity verification, the OpenRTB SupplyChain object adds a third layer: a real-time record of every entity that handled the bid request.

The SupplyChain object is embedded in the bid request itself and lists every node (seller or intermediary) in the chain. Each node references a seller_id that can be looked up in the respective advertising system's sellers.json.

Together, the three standards create a complete picture:

• ads.txt: Publisher declares authorized sellers
• sellers.json: SSPs declare seller identities
• SupplyChain object: Bid request traces the actual path from publisher to DSP

DSPs that implement all three can trace and verify the complete supply chain for every bid request.

Frequently Asked Questions

Do I need to set up sellers.json?

Publishers don't create sellers.json. SSPs maintain their own files. Your responsibility is maintaining ads.txt and ensuring your entries align with what SSPs report in their sellers.json.

How do I check if my ads.txt entries match sellers.json?

Manually: look up each SSP's sellers.json file and search for your account ID. Verify the seller_type and domain match your ads.txt claims. Automated: use BeamFlow's scanner to cross-verify all your entries at once.

What if the SSP takes weeks to update sellers.json?

This happens, especially with smaller SSPs. Keep communication open with your account manager. Document the discrepancy. In the meantime, your ads.txt entry for that SSP will fail sellers.json verification, which means reduced demand from that path.

Can ads.txt work without sellers.json?

Technically, yes. DSPs can check ads.txt for basic authorization without sellers.json. But increasingly, DSPs treat sellers.json verification as essential. ads.txt alone provides authorization but not identity verification. The trend is toward requiring both.