Definición profesional
sellers.json es una especificación de IAB Tech Lab que exige a las plataformas del lado de la venta (SSP, exchanges, ad servers) publicar un archivo público en la ruta /sellers.json de su dominio raíz. En ese archivo declaran la identidad legal de cada vendedor que opera bajo su plataforma, el identificador (seller_id) que ese vendedor usa en las solicitudes de puja OpenRTB y su rol en la transacción, que puede ser vendedor directo, intermediario o ambos. Junto con el objeto SupplyChain de OpenRTB, sellers.json forma el segundo pilar de la transparencia de cadena de suministro programática y complementa lo que ads.txt resuelve únicamente del lado del publisher.
Explicación sencilla
En términos simples, sellers.json es una lista pública que cada plataforma de venta programática publica en su propio sitio, donde cualquiera puede consultar quién es el dueño real de un espacio publicitario que se está vendiendo y quién más participa como intermediario en esa venta.
¿Por qué existe este concepto?
Antes de sellers.json, un comprador que recibía una solicitud de puja no tenía forma confiable de saber quién estaba detrás del seller_id que aparecía en esa solicitud. Los campos publisher.name y publisher.domain del objeto OpenRTB se completaban de forma inconsistente entre plataformas, lo que abría espacio para el inventario falsificado, donde un intermediario no autorizado revendía impresiones haciéndose pasar por el sitio original. IAB Tech Lab diseñó sellers.json para que el comprador pudiera verificar esa identidad de forma independiente, cruzando el seller_id contra un archivo público mantenido por la propia plataforma de venta.
¿Cómo funciona?
Cada plataforma de venta publica su archivo sellers.json en texto plano, accesible sin autenticación, en la raíz de su dominio. Por cada vendedor que opera en su sistema declara cuatro datos mínimos, que son el seller_id, el nombre de la entidad, el país de esa entidad y el tipo de rol (PUBLISHER, INTERMEDIARY o BOTH). Un comprador que recibe una solicitud de puja toma el seller_id de esa solicitud, lo busca en el sellers.json publicado por la plataforma emisora y confirma si la identidad declarada corresponde con la que espera. Cuando la solicitud incluye además el objeto SupplyChain de OpenRTB, el comprador puede repetir esa verificación para cada nodo intermedio de la ruta, no solo para el vendedor final.
¿Quién lo utiliza?
SSP o exchange. Publica y mantiene el archivo sellers.json, declarando cada seller_id que opera dentro de su plataforma y actualizándolo cuando se incorporan o dan de baja vendedores.
DSP o comprador programático. Consulta el archivo antes o durante la puja para confirmar que el vendedor declarado corresponde a una entidad autorizada, y aplica sus propias políticas de riesgo cuando encuentra inconsistencias.
Publisher. No suele publicar su propio sellers.json salvo que también actúe como intermediario, pero depende de que su SSP mantenga el archivo correcto, porque un seller_id mal declarado puede hacer que su inventario aparezca como no confiable ante los compradores.
Proveedor de verificación de cadena de suministro. Cruza sellers.json con ads.txt y con el objeto SupplyChain para detectar discrepancias entre lo que el publisher autorizó y lo que la plataforma de venta declara, y alerta a sus clientes cuando encuentra nodos no reconocidos.
Caso práctico
Un exchange programático recibe una solicitud de puja donde el publisher.id corresponde a un seller_id determinado. El DSP que evalúa esa puja consulta el archivo sellers.json publicado por el exchange en su dominio raíz y encuentra que ese seller_id está declarado como INTERMEDIARY, asociado a una razón social distinta de la que aparece en el nombre visible del sitio.
El DSP cruza ese dato con el objeto SupplyChain de la solicitud y confirma que existe un nodo adicional no declarado en el ads.txt del publisher original. Ante esa inconsistencia, el DSP aplica su política interna de riesgo, que puede ir desde descartar la puja hasta reducir el precio ofertado, sin necesidad de contactar directamente al publisher para validar la relación.
Error frecuente
Un malentendido habitual es suponer que la sola presencia de un seller_id en sellers.json garantiza que el inventario asociado está realmente disponible o que la transacción es legítima. El archivo confirma identidad, no disponibilidad ni legitimidad de cada impresión puntual. Otro error común es tratar sellers.json como sustituto de ads.txt, cuando en realidad son documentos complementarios que resuelven preguntas distintas.
¿Qué no es?
ads.txt. Ads.txt lo publica el publisher para declarar qué plataformas están autorizadas a vender su inventario. sellers.json lo publica la plataforma de venta para declarar la identidad de cada vendedor que opera bajo su sistema. Son documentos con autores distintos que se leen de forma cruzada, no el mismo archivo con otro nombre.
Objeto SupplyChain. El objeto SupplyChain viaja dentro de cada solicitud de puja OpenRTB y describe la ruta completa de nodos que intervinieron en esa transacción específica. sellers.json es un archivo estático publicado fuera de la solicitud, que sirve para verificar la identidad de cada nodo declarado en esa ruta, no para transportar la ruta en sí misma.
Certificado de calidad del inventario. Confirma quién vende el inventario, no la calidad, el contexto o la seguridad de marca del contenido donde aparecerá el anuncio.
Términos relacionados
Evolución histórica
IAB Tech Lab publicó la especificación sellers.json en julio de 2019, junto con el objeto SupplyChain de OpenRTB, como respuesta directa a las limitaciones de ads.txt, que había resuelto la autorización del lado del publisher pero no ofrecía forma de verificar la identidad de los intermediarios dentro de la cadena de venta.
El diseño original definió tres roles posibles para cada seller_id, que son PUBLISHER, INTERMEDIARY y BOTH, y estableció el mecanismo de lectura del archivo desde la ruta pública /sellers.json de cada dominio raíz. Desde entonces, IAB Tech Lab amplió el marco de verificación con el programa de validación de cadena de suministro (Supply Chain Validation), lanzado en 2021, que revisa de forma automatizada y periódica la consistencia entre los archivos ads.txt, app-ads.txt y sellers.json de los publishers inscritos.
Estándares relacionados
| Estándar | Organización | Relevancia |
|---|---|---|
| Ads.txt | IAB Tech Lab | Ads.txt autoriza del lado del publisher quién puede vender su inventario, mientras sellers.json resuelve la mitad complementaria verificando la identidad de esos vendedores autorizados, lo que permite cruzar ambos archivos para detectar vendedores no declarados. |
| App-ads.txt | IAB Tech Lab | Aplica el mismo principio de autorización de ads.txt al entorno de apps móviles, y se cruza contra sellers.json de la misma forma para verificar la identidad del vendedor en solicitudes de inventario in-app. |
| OpenRTB SupplyChain Object | IAB Tech Lab / OpenRTB Working Group | Transporta dentro de cada solicitud de puja la ruta completa de nodos que intervinieron en la venta, y sellers.json es el mecanismo que permite verificar la identidad declarada de cada uno de esos nodos. |
Empresas y tecnologías asociadas
Publican y mantienen archivos sellers.json las principales plataformas del lado de la venta que operan en el mercado programático global, entre ellas Google Ad Manager, PubMatic, Magnite, Index Exchange, OpenX y Xandr. La mención no constituye recomendación ni evaluación de ninguna de estas plataformas, y responde únicamente a que forman parte representativa del grupo de actores que implementan la especificación.
Pregunta frecuente
¿Un publisher necesita publicar su propio archivo sellers.json?
Solo si el publisher también actúa como plataforma de venta o intermediario para inventario de terceros. Si únicamente vende su propio inventario a través de SSP externos, la responsabilidad de publicar sellers.json recae en esos SSP, no en el publisher.