Servicio del licitador

Artículo
05/17/2024

El Servicio del Licitante conecta un postor con el bus de impresión de Xandr y permite que el postor y el bus de impresión comiencen a comunicarse. Su representante de Xandr creará el postor en el sistema y usará el Servicio del Licitador para realizar modificaciones o recuperar su id. de licitador.

Es posible que necesite su id. de postor para algunos de los Servicios. Para averiguar cuál es el identificador del pujador, ejecute el comando "Ver todos los licitadores" que se describe a continuación.

Algunas funciones del licitador solo son accesibles para determinados usuarios, ya que se basan en obligaciones contractuales:

Modificar los campos del proveedor de datos (a través PUTde ): requiere un contrato de acceso a datos con cada proveedor.

En los entornos de espacio aislado del licitador, toda la funcionalidad está disponible con fines de integración.

API de REST

Http (método)	Endpoint	Description
`GET`	https://api.adnxs.com/bidder/	Vea el pujador al que el usuario tiene permisos. No mostrará los postores de otros usuarios.
`GET`	https://api.adnxs.com/bidder/BIDDER_ID	Ver un pujador determinado.
`POST`	https://api.adnxs.com/bidder (JSON del licitador)	Agregue un nuevo postor.
`PUT`	https://api.adnxs.com/bidder/BIDDER_ID (JSON del licitador)	Modificar un pujador existente.
`DELETE`	https://api.adnxs.com/bidder/BIDDER_ID	Elimine un pujador existente.

Campos JSON

Campo	Obligatorio	Tipo	Description
`id`	Sí, al actualizar	Entero	El identificador del licitador.
`short_name`	Sí (al agregar)	string	Nombre corto opcional para el licitador. Aunque técnicamente no es necesario, este campo es necesario para las métricas, por lo que debe considerarse necesario. Nota: Solo se permiten caracteres alfanuméricos (A-Z, 0-9) y caracteres de subrayado. No use espacios, caracteres especiales, puntos u otros signos de puntuación.
`name`	Sí (al agregar)	string	Nombre asociado al licitador.
`active`	No, el valor predeterminado es true	Booleano	Si el licitador recibirá solicitudes o no.
`bid_uri`	Sí (al agregar)	string(255)	Uri de las solicitudes de puja (por ejemplo, `/bid`).
`notify_uri`	no	string (255)	URI para las solicitudes de notificación (por ejemplo, `/notify`). Use null, no una cadena vacía, para establecerlo en blanco. Nota: `notify_uri`- debe ser un URI relativo. Xandr no admite actualmente la colocación de `bid_uri` y `notify_uri` en hosts independientes. - Si es null, el licitador no recibe solicitudes de notificación.
`click_uri`	no	string(255)	Uri de las solicitudes de clic (por ejemplo, `/click`). Use null, no una cadena vacía, para establecerlo en blanco. Consulte Solicitud de clic.
`pixel_uri`	no	string(255)	URI de las solicitudes de píxeles (por ejemplo, `/pixel`). Use null, no una cadena vacía, para establecerlo en blanco. Consulte Solicitud de píxeles.
`ready_uri`	Sí (al agregar)	string(50)	Uri de una comprobación de estado de la instancia del licitador (por ejemplo, `/ready`).
`audit_notify_uri`	no	string(255)	Uri para pasar actualizaciones de auditoría creativa (por ejemplo `https://send.mycompany.com/auditnotifyrequests`, )
`parent_profile_id`	no	Entero	Identificador del perfil del pujador primario. Los perfiles del licitador se pueden usar para filtrar el tráfico de solicitudes de puja que llega a un licitador. Consulte Servicio de perfil de licitador heredado y Perfil de licitador - Preguntas más frecuentes.
`child_profiles`	no	Matriz de objetos con el identificador de los perfiles del licitador.	Matriz de objetos que especifican los perfiles secundarios que se van a usar. Por ejemplo: `[{"id":123}, {"id":124}]`.
`dongle`	no	string	Contraseña que protege la salida de depuración de un pujador en una impresión de depuración. Consulte `debug_text` en la respuesta de la oferta. Solo está disponible para usuarios de tipo "pujador".
`notify_full_auction`	no	Booleano	Establecer esto en "true" significa que el bus de impresiones incluirá `full_tag_info` y `bid_info` en la solicitud de notificación. Las notificaciones posteriores a la espera (`post_pending` establecidas `true` en en la solicitud de notificación) no incluyen estas etiquetas porque aún no se ha recibido la devolución de llamada de aceptación de la oferta.
`notify_lost`	No, el valor predeterminado es `false`	Booleano	Indica si se notifica al licitador todas las ofertas perdidas en el URI especificado en el `notify_uri` campo. Si no se proporciona ningún URI, no se envían notificaciones. - Si `true`es , el postor recibe una notificación sobre todas las ofertas perdidas. - Si `false`es , el licitador solo recibe una notificación sobre las ofertas perdidas con identificadores de código de error de solicitud de notificación superiores a 100. No registramos errores ni enviamos notificaciones perdidas si el identificador de error es menor que 100 para los licitadores de OpenRTB.
`notify_pending`	No, el valor predeterminado es `false`	Booleano	Indica si se notifica al licitador sobre las ofertas pendientes en el URI especificado en el `notify_uri` campo. Si no se proporciona ningún URI, no se envían notificaciones.
`notify_no_bid`	No, el valor predeterminado es `false`	Booleano	Indica si se notifica al licitador cuando el licitador no tiene ninguna oferta por una solicitud. La notificación se envía al URI especificado en el `notify_uri` campo . Si no se proporciona ningún URI, no se envían notificaciones.
`exclude_unowned`	no	Booleano	Excluir el inventario que no pertenece a un miembro asociado a este postor.
`send_unaudited`	No, el valor predeterminado es `false`	Booleano	Esta marca determina si el licitador se enviará o no al tráfico no auditado. Advertencia: En términos estrictos, este campo está en desuso, pero siempre debe establecerse en `true`. Si este campo está establecido en `false`, el pujador no recibirá ninguna solicitud de puja.
`bid_percent`	no	Entero	Porcentaje (50 = 50 %) del tráfico total de la plataforma que desea recibir. Las solicitudes que se envían al postor se eligen aleatoriamente, aunque puede elegir que el licitador reciba siempre solicitudes para los usuarios en segmentos de miembros asociados con el postor. Si establece bid_percent en 0, el pujador solo recibirá solicitudes de usuarios en al menos uno de los segmentos de sus miembros. Este filtro se aplica al tráfico que lo hace a través del servicio de perfil del licitador heredado.
`always_send_owned_segments`	no	Booleano	Determina si las impresiones de los usuarios en segmentos propiedad o compartidas con el Licitador deben omitir passthrough_percent en los perfiles del licitador. Nota: Esto solo invalida el passthrough_percent en el perfil del licitador; todas las demás restricciones, como los filtros de país, miembro, tamaño o dominio, se seguirían teniendo en cuenta al decidir si se enviará una impresión al licitador.
`object_limit_notify_email`	no	matriz de cadenas	Xandr limita el número de objetos que cada licitador puede crear y usar en la plataforma. Este límite incluye objetos inactivos y no utilizados. Este campo contiene las direcciones de correo electrónico que se notificarán cuando alcance el umbral del 85 %, 95 % y 100 % para los límites de objetos.
`protocol_id`	no	Entero	Solo lectura. Esto describe el protocolo asociado a este licitador, que describe el tipo de licitador que es. Por ejemplo, un `protocol_id` de `6` significa que este licitador usa la especificación de OpenRTB 2.0 para su integración con Xandr. El valor de integración predeterminado para un pujador recién creado es `1`, `none`. Este es el protocolo predeterminado definido en Solicitud de puja y Respuesta de puja. Los licitadores con un `protocol_id` de 6 se integran según las especificaciones de OpenRTB 2.0 (PDF). Especificación para OpenRTB 2.4, `protocol_id`: 10. Se admiten los siguientes valores (cada identificador va seguido del `protocol_name` asociado a ese identificador): - 1: `none` - 2: `wp7` - 3: `contentads` - 4: `admarket` - 5: `adexpert` - 6: `openrtb2.0` - 10: `openrtb2.4`
`protocol_name`	no	string	Solo lectura. Nombre del protocolo asociado a este licitador. Consulte la definición de `protocol_id` anterior para ver todos los valores aceptados de `protocol_id` y sus asignaciones a nombres.
last_activity	no	Timestamp	Marca de tiempo de la última modificación en esta instancia del licitador.
`max_seats`	no	Entero	Los licitadores que pujan con identificadores de puestos de comprador personalizados tendrán este campo con un valor mayor que 0. Este es el número máximo de puestos permitidos para ser inscritos bajo un postor. Nota: Esta característica se encuentra actualmente en versión beta cerrada. Si está interesado en participar, póngase en contacto con su representante de Xandr.
`default_member`	no	Objeto	Los licitadores que usen la oferta de id. de puesto de comprador tendrán un miembro predeterminado designado en este campo. Tenga en cuenta que el miembro predeterminado será el miembro de facturación principal del licitador y también se usará como identificador de miembro para el registro creativo. Nota: Esta característica se encuentra actualmente en versión beta cerrada. Si está interesado en participar, póngase en contacto con su representante de Xandr.

Nota:

Use el servicio de perfil del licitador para filtrar y limitar.

Para filtrar el tráfico que recibirá el licitador, use el Servicio de perfil de licitador heredado. Todavía existen algunos campos de filtrado y limitación en el Servicio del licitador, pero pronto se migrarán al Servicio de perfil de licitador. Los filtros de clase están disponibles en ambos; se recomienda usar el servicio de perfil del licitador para estos.

Campos en desuso

Campo	Obligatorio	Tipo	Description
`send_class_2`	No, el valor predeterminado es `true`	Booleano	Esta marca determina si el licitador recibirá o no tráfico de clase 2. Tenga en cuenta que la limitación por clase de inventario también es posible a través del servicio de perfil del licitador heredado.
`send_class_3`	No, el valor predeterminado es `true`	Booleano	Esta marca determina si se enviará o no el tráfico de clase 3 al licitador. Tenga en cuenta que la limitación por clase de inventario también es posible a través del servicio de perfil del licitador heredado.
`send_unaudited`	No, el valor predeterminado es `false`	Booleano	Esta marca determina si el licitador se enviará o no al tráfico no auditado. Nota: La limitación por clase de inventario también es posible a través del servicio de perfil del licitador heredado. Advertencia: Debe establecer este campo para ver las solicitudes de puja Debe establecer `send_unauditedtrue` en para que el licitador reciba solicitudes de puja. Para obtener más información, consulte Integración de un licitador.
`send_owned_blocklist`	no	Booleano	Enviar inventario de lista de bloqueos si pertenece a un miembro asociado a este postor.
`userdata_entity_id`	no	Entero	Este campo está en desuso.
`userdata_javascript`	no	string	Funciones de JavaScript personalizadas a las que se puede llamar cuando un licitador actualiza los datos de cookies de un usuario.
`setuid_function`	no	string	Nombre de la función de JavaScript que se va a usar en las llamadas SetUID .

Ejemplos

Token de autenticación

La autenticación siempre es el primer paso cuando se usan los servicios de API. A continuación, el token de autenticación se puede escribir en nuestro archivo de cookies para su uso futuro. Para obtener instrucciones más detalladas, consulte Servicio de autenticación.

Visualización de la información del licitador

Si Xandr ya ha agregado el postor, ya tendrá información sobre el pujador, como el identificador del pujador, en formato JSON. Puede ver esta información con el siguiente comando.

S curl -b cookies -c cookies "https://api.adnxs.com/bidder"
{
   "response":{
      "status":"OK",
      "bidder":{
         "id":4,
         "name":"Test Bidder",
         "short_name":"TestBidder",
         "active":true,
         "parent_profile_id": 12345,
         "child_profiles":[{"id":1000},{"id":2000},{"id":3000}],
         "bid_uri":"/bid",
         "notify_uri":"/notify",
         "click_uri":null,
         "ready_uri":null,
         "pixel_uri":"/pixel",
         "audit_notify_uri":null,
         "last_activity":"2009-01-07 22:07:08"
      }
   }
}

Modificación de un pujador

Ahora que conoce el identificador del pujador, puede usar un archivo de texto en formato JSON para modificar el pujador. A continuación se muestra un JSON de ejemplo que cambiará el parámetro de URI ready.

Nota:

Estos campos incluidos se actualizarán. Todos los demás campos no se modificarán.

$ cat bidder
{
      "bidder":{
         "id":4,
         "ready_uri":"/ready"
      }
   }

A continuación, use el PUT comando para actualizar estos datos en la caché del bus de impresiones.

$ curl -b cookies -c cookies -X PUT --data-binary @bidder 'https://api.adnxs.com/bidder/4'
{
   "response":{
      "status":"OK",
      "id":4
   }
}

Ahora, cuando vea el Licitador 4, obtendrá lo siguiente:

$ curl -b cookies -c cookies 'https://api.adnxs.com/bidder/4'
{
   "response":{
      "status":"OK",
      "bidder":{
         "id":4,
         "name":"Test Bidder",
         "short_name":"TestBidder",
         "active":true,
         "parent_profile_id": 12345,
         "child_profiles":[{"id":1000},{"id":2000},{"id":3000}],      
         "bid_uri":"/bid",
         "notify_uri":"/notify",
         "click_uri":null,
         "ready_uri":"/ready",
         "ready_string":"Ready:1"
         "pixel_uri":"/pixel",
         "audit_notify_uri":null,
         "last_activity":"2009-01-07 22:07:08"
      }
      }
}

Compartir a través de

Servicio del licitador

API de REST

Campos JSON

Campos en desuso

Ejemplos

Token de autenticación

Visualización de la información del licitador

Modificación de un pujador

Recursos adicionales

Compartir a través de

Servicio del licitador

API de REST

Campos JSON

Campos en desuso

Ejemplos

Token de autenticación

Visualización de la información del licitador

Modificación de un pujador

Temas relacionados

Recursos adicionales