Ads.txt Mobile Web

What is Ads.txt?

Authorized Digital Sellers (ads.txt) is an initiative originated in 2017 by the IAB Tech Lab. This initiative increases transparency in the ecosystem of programmatic advertising by eliminating the chances of unauthorized buying and selling transactions. Authorized Digital Sellers for Apps (app-ads.txt) extends the ads.txt standard to support mobile apps distributed through online app stores. This is done by linking an ads.txt file with the app developer websites and posted to the app store listings.

Smaato supports the IAB Tech Lab initiative for ads.txt/app-ads.txt. For this, we are designing and implementing a snippet generator into our SPX platform to allow for easy adoption by our publishers. We currently working the release and will inform everyone shortly about this.


How Do Buyers Benefit?

The goal of the specification is to increase the transparency of the programmatic marketplace. With ads.txt, DSPs can use crawlers to parse the information from publisher’s inventory and rule out the counterfeit inventory and unauthorized arbitragers.

How to Make Use of Ads.txt?


  • Ads.txt should be placed under the root folder of the website’s root domain (rather than subdomains), e.g.:
  • If ads.txt does not exist, it’s assumed that anyone is authorized to resell the inventory.

File format

  • Each line represents an authorized seller.
  • Defined by IAB Ads.txt specification, each line could contain up to 4 fields, which are separated by commas. There could be spaces between each field.
  • Comment lines are initialed by # symbols.
  • Sample codes for an ads.txt crawler can be found here.


The domain name of the advertising system

(Required) The canonical domain name of the SSP, exchange, header wrapper, et.c system that bidders connect to. This may be the operational domain of the system, if that is different than the parent corporate domain, to facilitate WHOIS and reverse IP lookups to establish clear ownership of the delegate system. Ideally, the SSP or Exchange publishes a document detailing what domain name to use.


Publisher’s Account ID

(Required) The identifier associated with the seller or reseller accounts within the advertising system in field #1. This must contain the same value used in transactions (i.e. OpenRTB bid requests) in the field specified by the SSP/exchange. Typically, in OpenRTB, this is For OpenDirect it is typically the publisher’s organization ID.



Type of Account/Relationship

(Required) An enumeration of the type of account. A value of ‘DIRECT’ indicates that the publisher (content owner) directly controls the account indicated in field #2 on the system in field #1. This tends to mean a direct business contract between the Publisher and the advertising system. A value of ‘RESELLER’ indicates that the Publisher has authorized another entity to control the account indicated in field #2 and resell their ad space via the system in field #1. Other types may be added in the future. Note that this field should be treated as case insensitive when interpreting the data.





Certification Authority ID

(Optional) An ID that uniquely identifies the advertising system within a certification authority (this ID maps to the entity listed in field #1). A current certification authority is the Trustworthy Accountability Group (aka TAG), and the TAGID would be included here [11].


Sample Values:,1000012345,DIRECT, 1000012346, RESELLER

Server Response Handling

Response code:

  • By definition, only the HTTP 2xx status code would be supported by the publisher server.
    • HTTP 3xx status codes are not supported at the moment.
    • HTTP 4xx and 5xx status codes should be read as errors.


  • Standard HTTP cache-control mechanisms and crawlers should read the information properly. If no cache-control directives are present, a default expiry of seven days is assumed.

Supported Documentation

IAB App-ads.txt Specifications (for Apps):

IAB Ads.txt Specifications (for Web):

Doc Feedback Product Feedback

Last Modified: November 29, 2021 at 2:11 pm