Entries with tag publisher api .

Retrieving all available programs via the Publisher API 2011

The end of last year marked the end-of-life and end of support for the 2009 version of the zanox Publisher API. Applications and tools, based on this API had to be migrated to use the newer – the 2011 version. Some helper tools that we have built for you at zanox will not be migrated, however, as we have made same data and functionality available in the newer version of the API.

Update: Please take a look at our new API-Widget. All Publisher Api Methods are available for testing in an easy to use Interface. Visit the Widget here.

Step 1: get your API credentials
To do that, just login into zanox marketplace and under “Links & Tools” click on the Web Services API > Getting Started.

On the Getting Started page, you will see your Connect ID and Secret Key, those are your API credentials. To retrieve the program list, you will only need your Connect ID.

Step 2: retrieve the program list
Insert your Connect ID into the following link (remove the curly brackets) and use it to retrieve the program list.
http://api.zanox.com/xml/2011-03-01/programs?connectid={Your Connect ID}&items=50&page=0

The result will be the first 50 programs and program details from the zanox program list in XML. 50 is the maximum number of items that our API can return in one page. The response will also include the total number of items:

<SearchProgramsResponse xmlns="http://api.zanox.com/namespace/2011-03-01/">

First page number is zero. To see the next result page use the pagequery parameter in the URL, as highlighted below:
http://api.zanox.com/xml/2011-03-01/programs?connectid={Your Connect ID}&items=50&page=1

You will have to write a small script to iterate through pages to retrieve the full list of programs. The results are available in XML or JSON. The response type is in the URL as highlighted below. This example would return JSON:

http://api.zanox.com/json/2011-03-01/programs?connectid={Your Connect ID}&items=50&page=1

So there you have it!

EAN and merchant category filters in the product search API

As the beta phase of the new product search aproaches the end, we continue rolling out the features. Today, we are happy to present you two latest additions to the API interface - the EAN and the merchant category filters.

EAN filter

You can now search for products using the unique international article number - the EAN. It's a great filter for all those barcode scanner applications, which don't have any other keywords to use. EAN can be passed as a query parameter and will limit the results to matching products only. Even though EAN uniquely identifies a product, it is possible that you will get multiple results if several merchants have the same item for sale. Here's an example request to find the Galaxy Note 10.1 (ean 8806085308091):


Response contains two products from different merchants (cropped for readability):

<productItem id="b3d8b8ac4dd085a5b7a239b61ce5beb6">
    <name>Samsung Galaxy Note 10.1 WiFi TM 16GB white (GT-N8020ZWADBT)</name>
    <category id="7000000">Computers & Software</category>
    <merchantCategory>Computer + Büro</merchantCategory>
<productItem id="9cf344f049b0289e5016dff4262b75ff">
    <name>Samsung Galaxy Note 10.1 N8020 LTE white</name>

Please note that not all merchants provide EANs for their product data feeds, therefore not all products in our database can be found using their article number.

Merchant category filter

Most shops use their own category tree to organize products. They are different from merchant to merchant, but make good and reliable search criteria if you want to get the best possible search result for a specific merchant. We are therefore adding the functionality to filter products by the merchant category or several categories. Like EAN, merchant category can be passed via REST URL query parameter. You can also pass multiple categories, from the same or different merchants by repeating the query parameter. For example, if you wanted to search for Samsung tablets and notebook PCs, you could formulate a query like this:


It returns multiple products from both categories, two of which you can see below (cropped for readability):

<productItem id="92544ec116ba54cf87175675521e88a4">
    <name>Samsung Notebook NP370R5E-S01CH</name>
<productItem id="e1cb94e83497cf8c11760871c56847bf">
    <name>Samsung Galaxy TAB2 7.0” WIFI 8GB</name>

We will be extending our API in the near future to allow you to download merchant-defined category trees, in order to enable you to use the full potential of this feature.

Both of the new filters are also documented in the Publisher API 2011 reference.


Updated: retrieving all merchant's categories

We have also added an API resource that returns all product categories for a selected merchant. For example you can get categories for Fab.com EU (ID 13299) like this:


Response at the time of writing is (cropped for readability):

        <category>Women / Necklaces</category>
        <category>Home / Unframed Prints</category>
        <category>Home / Workspace</category>
        <category>Home / Kitchen Tools</category>
        <category>Home / Bed Linens</category>
        <category>Home / Serveware</category>
        <category>Women / Watches</category>
        <category>Women / Bangles</category>

Currently we have identified a few programs that provide low quality category data or do not provide it at all. Therefore this resource will not return categories where it detects that data is not correct. We will be working with advertisers to improve EAN and category data quality over time.

Retiring zanox product category tree

With merchant category filters now active in our product search API, we will be discontinuing our old zanox product category tree and the related API filter on January 1st, 2014.


First, a bit of background on how current categorisation works. Products are assigned to a zanox category automatically, using a machine-learning algorithm, which makes this decision based on keywords in the product name, description and other fields. This approach allows us to categorise products independently of how much information is provided and does not force merchants to adopt (or map to) the zanox category tree. But as with all machine-learning algorithms - it is not perfect, especially when it comes to recognising same items in different languages or spotting a difference between a real item and its accessory (e.g. iPad and iPad case).

Changes and solutions

To address these shortcomings, we have already introduced result filtering by merchant categories and today we are announcing discontinuation of the current zanox product categorisation. Existing clients will continue working without changes until the 1st of January 2014. After that, queries using the old category IDs will return an empty resultset without errors. 

We advise you to rely on search keywords and merchant categories if you need better filtering.

New in the REST API: sales basket items

We are happy to present you the latest addition to our API resource family - the sale basket. As you might know a single sale can contain multiple products, which can belong to different categories and have different commissions. While the Publisher API has always had a resource to get sales or an individual sale, the response included an undefined commission and a "basket" as tracking category in case of multiple products in a single sale.

To cover this gap, we now introduce a new basket resource, which, among other properties, returns products in the sale basket, their respective tracking categories and commissions. A basket item looks like this:

   <productName>Apple iPad 4</productName>

To get the basket, you will have to provide the sale ID as a REST URL path parameter. Sale IDs are returned by the aforementioned sales resource. The basket resource is protected, so you will need to generate the zanox OAuth signature as described in the authentication documentation. This functionality is implemented in REST API only, with the usual XML or JSON response formats to choose from.

For more information, please refer to the sales basket documentation page.

Rebuilding the search

The shut-off of the zanox Shop@ network in November of last year made searching products and AdMedia in the API much more complex. Without the pool of freely available ads and products, each search query now requires a list of program IDs where the publisher is confirmed. No results are returned if this list is not provided. This is often cumbersome, as getting your confirmed program IDs requires making another API call, or a number of them if you are accepted to more programs than the maximum result page size.

Based on this feedback we decided to improve a thing or two to make lives of our developers easier. As it happens, a small feature request evolved into a full-scale rebuild of zanox search infrastructure and today I am happy announce that we are nearly there!

Without going too much into detail, I can still provide some insight for the tech-savvy. Parallel to not-the-latest-version Lucene, which drives our current product search, we have built up a fully-automated Solr 4 environment.

So what can you expect? Well, several things, actually.

Near real-time product availability in search

The first thing we improved on is delay between importing products from the Advertiser to their availability in search results. While current system refreshes its index once a day - at midnight, the new search will continuously index new products as they come in. So the delay will be reduced from the maximum of 24h to around the maximum of 45m. That's how long it takes us to index our biggest product feed. Averages should be much lower though - 10-20m.

Search in all confirmed programs without providing program IDs

The default behaviour of search was changed to automatically search all confirmed programs if no program IDs are provided in the search query. This way, developers will save the before-mentioned API call(s) to retrieve all program IDs.

Search products of all zanox programs without applying

Have you ever wondered which programs have products relevant to you? Now you can search within all programs with the URL query parameter partnership=all. Note, that no tracking links will be returned for programs, that have not confirmed you.

Fixing known bugs

Many of you are familiar with API returning less than 50 items in one page, even though total results is much bigger than 50. This behaviour is also described in the known bugs section of the product search documentation.


This issue has been addressed in the new search version.

One important feature that is NOT in the current Beta is product categories. We are still working on improved machine learning algorithms that categorize the products, and we will add it in the near future.

We see the above features as must-haves for the rollout. But the new technology will enable us to add more bells and whistles in the future development iterations. What we have in the "pipe" is improved product categorization, better performance and in the long-term - also moving admedia search and program search onto the new backend.

Looks good, so when is it going into production? Well, actually it is live already, first accessible via our REST API. The main stream of requests is still chanelled to the old search, but if you append the query parameter solr=true to the resource URL, your results will come from the Solr cluster. The developer team is still measuring and tuning the performance, writing automated tests and fixing any "teething issues", but it is there for everyone who wants to test it out.

When we are sure that the new search meets our quality expectation, we will start switching more and more requests to the new backend. The good news for you, the developers? You don't have to add a single line of code, the API interface remains the same. If you want to switch over to the new search before we do it for you - you can use the solr=true parameter. Additionally, you don't have to provide any program IDs, unless you want to limit results to those particular programs. Here's an example:


Having said that, we would be very happy to hear from the early adopters, trying out our search. What are your impressions? What works, what doesn't and what can we improve? Head to the documentation section to read about the new parameters and their usage.