As stated before, any product field can have one picture assigned to it. The same picture can be referenced by many fields, and many products, in several languages.
Pictures are uploaded to Mediablob by calling UploadImage2 or UploadAndClipImage. When an image is uploaded, its md5 hashCode is returned. Use this hashCode as future reference in products.
To reduce bandwidth usage, api users are encouraged to calculate the md5 hash code themselves and check if the image exists in Mediablob through the ImageExists or ImageExistsMd5 functions prior to uploading images.
Note: Images are always hashed before being processed by Mediablob services, so it can be correctly precalculated before uploading.
Note: It is not possible to delete images in Mediablob through the API.
While our SOAP based webservice will remain in operation for some time longer, it is no longer being maintained and will not be updated with bug fixes, etc. If you are already using the SOAP based service we recommend that you switch over to using our REST based service at your earliest convenience. If you are integrating your system to ours for the first time, we strongly urge you to use the REST based service, not the SOAP based one.
The SOAP specific documentation will remain online as long as we accept SOAP requests, only as a convenience to our customers currently using it. Again, if you are building a new integration, use REST instead.
Soap is a standard protocol that will not be discussed in detail here. There are some peculiarities to know about when integrating with Mediablob though; specifically Mediablobs use of an <AuthHeader /> section.
Another quirk, that is handled automatically by tools such as Visual Studio, is that xml content must be xml-encoded.
Mediablob does not use any cookies or other common login mechanisms to validate access. Instead Mediablob expects an AuthHeader section in the soap header.
The AuthHeader looks like this:
The username and password authenticates the user. Mediablob then verifies the users privileges and authorizes the rest of the request.
The customerId is used to instruct Mediablob which customer node the uploaded xml file relates to. The customerId can either be a ShoppaID assigned by Shoppa when the customer node was created, or an ExternalID assigned to each store by the customer.
Contact Shoppa Service Center to change what ExternalID to use for different stores.
The customerId must always be for or below the node the user logs in to. To prevent pre-generated xml-files to be uploaded to the wrong account by mistake, the customerId must correspond with the customerId of the uploaded xml file.
The content of any xml element must be xml encoded. This is achieved by replacing each character with its encoded counterpart. Thus, in the Mediablob product xml you would need to encode the product text Köp & vinn! as Köp & vinn!.
Xml encoding is automatically handled by high-level frameworks like C# and Java. You only need think about this when you create your xml file manually.
What can be a bit confusing is when you wrap the Mediablob xml in soap. Since your xml file is content in a soap element, it needs to be xml encoded, including any text you encoded inside your xml. The product text above would then become Köp &amp; vinn!.
Mediablob also requires an xml declaration line at the top.
Lets say we want to upload the following product definition:
Using the following user details:
username: demouser1
password: Not_a_real_password
ShoppaID: 1143
Encoded and wrapped in a valid soap request this becomes:
Copy this text and POST it with Wizdler to Mediablobs development endpoint. You should get the following response with status code 200 if you did it right: