ZEDO’s Supply Side Platform (SSP), powered by our world-class technology, provides Demand Side Platforms with access to ZEDO’s premium high-quality display, video and native inventory. Advertisers get complete control over the spend, with the ability to pay different values per impression.



The following sequence summarizes the bidding, selection and ad serving flow:

  1. A user visits a Publisher’s website associated with ZEDO’s SSP and an ad serving request is received via the user’s browser.
  2. ZEDO initiates bid request to the Demand Side partners/buyer’s system from the server.
  3. Each Buyer/Demand Side partner returns bid value that the Advertiser is willing to spend for a user and ad code.
  4. ZEDO SSP conducts the auction and selects the highest bid and notifies the winning buyer.
  5. ZEDO SSP serves the ad received from the winning buyer to the user.


Integration Specifications

ZEDO’s Supply Side Platform is OpenRTB 2.3 compliant. It is also backward compatible to send requests in OpenRTB2.2 and OpenRTB2.0 (without deals) format if needed.

For complete details and specifications please refer:





Bid Request

ZEDO RTB bid request to the buyer will include all the fields marked as Required in the OpenRTB standard document, as well as the Recommended and Optional fields that are defined below. Additional fields can be added on request.

Field Sub-Field Description
site id ID in ZEDO RTB System
domain Domain of site
cat IAB content category ID (List 5.1 in IAB OpenRTB 2.3
 page Page URL if available
publisher Complete object [containing id, name, cat and domain]
 app  id ID in ZEDO RTB system
 name App Name
bundle Application bundle or Package name on app store
domain Domain of the app
cat IAB content category ID (List 5.1 in IAB OpenRTB 2.3)
privacypolicy Indicates if the app has a privacy policy (0-No, 1=Yes)
paid Indicates if app is paid or free (0=free, 1=paid)
publisher Complete object [contianing id, name, cat and domain]
user id User ID in ZEDO RTB system
buyerid DSP’s user id if available. IDFA or Android Id for the App traffic
device ua Browser User Agent string
ip IPv4 address closest to device
language Browser language using ISO-639-1-alpha-2
js Support for javascript, where 0=No, 1=Yes
devicetype The general type of device
make Device make (e.g. “Apple”)
os Device Operating System (e.g. “iOS”)
osv Device Operating System version (e.g. “3.1.2”)
ifa ID sanctioned for advertiser use, for example Apple’s IDFA or Android’s Advertising ID
h Physical height of the screen in pixels
w Physical width of the screen in pixels
ppi Screen size as pixels per linear inch
pxratio The ratio of physical pixels to device independent pixels
at Auction type 1 or 2 as per mutual decision
tmax Maximum timeout, default will be 80
bcat Blocked Advertiser categories values as per IAB content categories
badv Blocked top level demains. Comma separated domain names


Under the mandatory “imp” object, the following sub-fields will be included. Either ‘banner, video or native’ will be present depending on the request.

Field Sub-Field Description
banner w Width of creative
h Height of creative
battr Blocked creative attributes. Absent by default, will be included on request.
video mimes List of supported MIME types
linearity 1 for linear, 2 for non-linear
minduration Minimum ad duration in seconds
maxduration Maximum ad duration in seconds
protocol Supported response VAST versions e.g. VAST 2.0/VAST 3.0 wrapper etc
w Width of the player
h Height of the player
companionad Supported VAST companion ad type
battr Blocked creative attributes
playbackmethod Allowed playback methods. If not specified, assume all are allowed
api List of supported api frameworks for this impression
native ver Version of the Native mark up version in use. Default value 1.
layout The layout id of the native ad unit
adunit The ad unit of the native ad unit
plcmtcnt The number of identical placements in this layout.
assets An array of asset objects. Any bids must comply with the array of elements expressed by the exchange e.g. id, required, title, video, image, data


Private Marketplace (PMP)

For the Private Deals (using Deal Id), pmp object will be included under the “imp” object.

Field Sub-Field Description
private_auction 1 indicates strictly private auction. 0 indicates that all the bids are accepted, not only the private ones
deals Collection of “deal” objects
deal id Deal id string
bidfloor Bid floor for this impression (in CPM)
at Auction type for this impression
wseat (optional) Array of buyer seats allowed to bid
wadomain (optional) Array of advertiser domains allowed to bid


We do not support, ext field under pmp object yet, that is used for sending custom JSON. It can be added if required for any use case.

Display Bid Request Example


  "id": "BID-1-ZIMP-585f8d50-2fed-4ef1-a4ce-0f4894f88a3f",
  "at": 2,
  "tmax": 180,
  "imp": [{
    "id": "ZIMP-585f8d50-2fed-4ef1-a4ce-0f4894f88a3f",
    "bidfloor": "1.00",
    "banner": {
      "w": 300,
      "h": 250,
      "pos": 1
  "site": {
    "id": "50",
    "name": "TestSite",
    "domain": "website.com",
    "cat": [""],
    "page": "http://www.website.com/",
    "ref": "",
    "publisher": {
      "id": "29",
      "name": "ZEDO Test Publisher_2",
      "cat": [
      "domain": "zedo.com"
  "device": {
    "ua": "Mozilla/5.0 (Windows NT 6.2; rv:28.0) Gecko/20100101 Firefox/28.0",
    "ip": "",
    "language": "en-us,en;q=0.5"
  "user": {
    "id": "fba66dad-2093-40da-8ec7-407157cd3513",
    "buyeruid": "Wn5pZ1JwQnlLEGRJAgB4WQU"
  "bcat": [
  "badv": [


For the Video request, the section marked in blue in the example above differs and it contains the “video” object in place of “banner”.



PMP Request Sample

"imp": [{
    "deals":[ {
      "wseat":[ "Agency1" ],
      "wseat":[ "Agency2" ],


Native Request Sample

Similarly, for Native Bid Request the section marked in blue in the display example above differs and it contains the “Native” object in place of “banner”.

“native”: {“request”: “{\”ver\”:\”1\”,\”layout\”:7,\”adunit\”:4,\”plcmtcnt\”:3,\”assets\”:[{\”id\”:1,\”required\”:1,\”img\”:{\”type\”:3,\”wmin\”:125,\”hmin\”:89}},{\”id\”:2,\”required\”:1,\”title\”:{\”len\”:60}},{\”id\”:3,\”required\”:1,\”data\”:{\”type\”:1,\”len\”:60}}]}”


In-App Request Sample

Similarly, for In-App Bid Request the section marked in orange in the display example above differs and it contains the “App” object in place of “Site”.

  "name":"App Name",
  "name":"Publisher A",


For complete details and specifications please refer:



Bid Response

  • We support a JSON Format as per OpenRTB standard. Multiple bids are supported.
  • We give higher priority to PMP Bids than OpenMarket.
  • For Video response, please follow the table below.
Adm nURL


  • Default Pricing Units:
    • Price in ‘adm’ field – CPM
    • Bidfloor in bid request – CPM
    • Price in bid response – CPM


Refer example:

1) bid request sent with floor prince $0.01

2) bid received by ZEDO with bid price = $2.0 (CPM)

3) win price settled at $1.5 (CPM)

4) macro will be replaced with value $1.5 (CPM)


If 1000 wins are recorded the revenue in ($) will be $1.5


Our Bid Response object follows the model specified by IAB OpenRTB Specification version 2.3. For details see below:

Field Sub-Field Description
BidResponse id ID of the bid request to which this is a response
bidid Bidder generated response ID to assist with logging/tracking
seatbid Array of seatbid objects; 1+ is required if a bid is to be made
cur Bid currency


The seatbid object should contain an array of Bids:

Field Sub-Field Description
Bid impid ID of the Imp object in the related bid request
price Bid price expressed as CPM
nurl Win notice URL called by the exchange if the bid wins
adm Optional means of conveying ad markup
adomain Advertiser domain for blocklist checking
dealid Reference tot he deal.id from the bid request if this bid pertains to ta private marketplace direct deal


User Matching

ZEDO will initiate the user matching by calling the User Matching URL provided and the DSP partner is expected to redirect (302 redirect) to ZEDO’s user matching URL, with user id specified in a placeholder.

You can either provide us with a placeholder which we can populate with ZEDO’s matching URL at run-time or we can email it to you offline, if you do not want a run-time approach.

ZEDO’s user matching tag will contain a placeholder, which is expected to be populated with the user id of the DSP.

Sample URL: http://sub-domain.zedo.com/rs/us/fcm.html?pid=1&usr=[INSERT_USER_ID]

By default the user Id specified in the above URL is not decoded before setting it in ZEDO domain, it can be done on request.

0 0