ℹ This page describes the suggested and currently most effective way to create listings/offers on refurbed. Listing requests created this way will be treated with higher priority than via email.
All services and operations concerning the offers must be called with CatalogService or OfferService in the URL followed by the command/operation.
E.g.: https://api.refurbed.com/refb.merchant.v1.OfferService/BatchCreateOffers
or
https://api.refurbed.com/refb.merchant.v1.CatalogService/GetCatalogTemplates
All calls must be done using POST method.
Our Next Gen Listing workflow allows you to send us your to be listed product and offer data in one action in contrary to our previous workflow, where listing and offer creation were two separate steps, and only offer creation was available in the Seller API.
This new workflow is a more commonly used template based workflow as it is used by many platforms and provides more convenience and scaleability to you.
Get Templates (GetCatalogTemplates)
⚠ Currently available category templates: Laptops, Desktops, Tablets, Audio, E-Bikes, Smartwatches, Accessories, Cameras, Consoles, Monitors, Printers, Smartphones and TVs. More will be added soon.
This method exposes our category templates. Provide category_type (ELECTRONICS, SPORTS or KIDS) and lang_code (DE, EN) in the request payload to retrieve all category templates for a certain category type at once. You can also specify a specific category_id to only receive the template of a certain category. On the root of the response object you will find category_id, category_name, child_templates and version. While category_id and category_name specify what their names imply child_templates will expose if there are more specific templates available for sub categories; version is incremented every time we do an update on a template.
The constraints section holds the template definitions as a list of objects, whereas each product attribute is represented by one object:
| field name | description |
|---|---|
| attribute_key | This value has to be used as key when sending us a listing request, e.g.: screen_size or operating_system. |
| attribute_name | Human-readable name of the attribute key e.g.: Screen Size or Operating System, The localization of this name depends on the chosen lang_code in the request (DE, EN). |
| presence | Indicates whether the attribute is either REQUIRED or OPTIONAL in the listing request. |
| known_values | For some attributes we will expose commonly used values in our product data to provide guidance on expected values sent in a listing request e.g.: yes/no In most cases these are example values and not an exhaustive list, more values might be possible. |
| value_type | Specifies the expected value type e.g.: INTEGER, DECIMAL or STRING
|
| description | Here we provide additional information e.g. examples or formatting hints. Localization of this text depends on chosen lang_code sent in the request. |
| unit | This field is only visible for numeric attributes where we expose the unit to be used in the listing request, e.g.: GB
|
Example response:
{
"templates": [
{
"constraints": [
{
"attribute_key": "operating_system",
"attribute_name": "Operating System",
"presence": "REQUIRED",
"known_values": ["Windows 11 Home", "Windows 11 Professional"],
"value_type": "STRING",
"description": "iOS/Android/Windows"
},
{
"attribute_key": "ram_size",
"attribute_name": "RAM Size",
"presence": "REQUIRED",
"known_values": [],
"value_type": "STRING",
"description": "With units e.g. 4 GB",
"unit": "GB"
},
[ ... ]
],
"category_id": "6",
"category_name": "Tablets",
"childTemplates": [
{
"constraints": [
{
"attributeKey": "case_material",
"attributeName": "Gehäusematerial",
"presence": "OPTIONAL",
"knownValues": [
"Glas",
"Plastic",
"Metal"
],
"valueType": "STRING",
"description": ""
},
{
"attributeKey": "case_colour",
"attributeName": "Case colour",
"presence": "OPTIONAL",
"knownValues": [
"Blue",
"Red",
"Green"
],
"valueType": "STRING",
"description": ""
}
],
"categoryId": "36",
"categoryName": "Microsoft Tablets",
"version": "1"
}
],
"version": "1"
}
]
}
Create Listings/Offers (BatchCreateOffers)
ℹ The new workflow was implemented into the existing BatchCreateOffers method to allow an easier adoption of your already existing implementation. It is fully backwards compatible and it is still possible to simply create offers as described Offers . The new listing workflow cannot be used with the single action route (CreateOffer) as this is not the preferred and suggested method to create Listings/Offers due to performance reasons.
To create a new listing and offer we expect you to send us your product data in accordance with our outlined templates for respective category as well as offer related data like stock, price information, grading etc.
We will explain the product data part first and then the offer data part, which you might already be familiar with, if you used it before, in this case you can skip the second part.
Submitting a Listing Request
Our BatchCreateOffers method is designed to be able to take offer and product data for up to 50 items. In the request payload you need to provide a list of listing requests whereas every object can include an instance_descriptor section:
| field name | required | description | type |
|---|---|---|---|
| lang_code | ✅ | Specifies the language of the provided values, currently supported DE and EN
|
string |
| instance_name | ✅ | Full name of the product for the listing request defined in sellers inventory system, should use language specified in lang_code e.g.: Lenovo ThinkPad E570 |
string |
| category_id | ✅ | Provide refurbed’s category_id, e.g.: 2 for Laptops, is revealed via GetCatalogTemplates method |
string($int64) |
| specification[0].key | ✅ | specification object expect a list of key, val objects. Provide key as specified in template (attribute_key). It is usually English and snake_case |
string |
| specification[0].val | ✅ | Provide value in language specified in lang_code and as specified in template. Consider known_values, value_type, unit and description. Include all key, val pairs that are REQUIRED
|
string |
| hints.refb_product_id | ❌ | hints object expects a set of useful matching hints. If provided, our matching system will only consider variants of this product for your request, new variants will be created only for this product | string($int64) |
| hints.google_category_id | ❌ | Identifier of category as per the Google Product Taxonomy. Using Google Product Taxonomy will allow us to map the proper category the offer will be created in | string($int64) |
| hints.gtin | ❌ | If you provide specification and can provide a GTIN-13, submit it here. It helps us with identification and matching. You can omit the use of the gtin field in the root of the request (offer data) |
string |
| hints.mpn | ❌ | If you provide specification and can provide a manufacturer part number (mpn), submit it here. It helps us with identification and matching You can omit the use of the mpn field in the root of the request (offer data) |
string |
ℹ specification, instance_id, gtin and mpn are one_of fields of the same group, meaning you need to provide either of these in your request.
It is possible to submit key, val objects in the specification, that are outside the constraints as defined per template. They may help us identify and create a product more easily, however they will not have any influence on matching.
The above data concludes the product data part of your listing request, the complete your request you need to provide offer data:
| field name | required | description | type |
|---|---|---|---|
| instance_id (one_of) | ❌ | refurbed’s internal reference number, can be found in our product catalog (download in the seller interface). Any of the one_of fields should be provided, if all are ommited specification is needed | string($int64) |
| gtin (one_of) | ❌ | Provide a GTIN-13 to create an offer immediately with this identifer (if we have it associated to an instance already). Created offers will be in UNVERIFIED state and require manual action in the seller interface. |
string |
| mpn (one_of) | ❌ | Provide a manufacturer part number to create an offer immediately with this identifer (if we have it associated to an instance already). Created offers will be in UNVERIFIED | |
| state and require manual action in the seller interface. | string | ||
| sku | ✅ | SKU that will be connected to the offer, it will be the reference if you e.g. want to offer updates via API. MUST be unique. | string |
| reference_min_price | ❌ | Defines a lower price limit for buybox competition. | string |
| reference_price | ✅ | Offer price including VAT. Eventual shipping costs set in your shipping profile will be added to the sales price. | string |
| reference_currency_code | ✅ | Offer currency as ISO 4217 code. | string |
| stock | ✅ | The quantity available of the item. | integer($int64) |
| grading | ✅ | AA, A, B or C. Please refer to our Quality charta | string |
| warranty | ✅ | Allowed value is M12. M = Months. | string |
| shipping_profile_id | ✅ | ShippingProfile ID can be found in the merchant backend > Shipping profiles section. The chosen ID will be connected to the offer. |
string($int64) |
| taxation | ✅ | The applicable taxation of the item (MARGINAL or GROSS) | string |
| battery_condition | ❌ | State of the battery the offer is sold with (OPTIMAL or NEW). Omitting the field will result in value UNSPECIFIED. | string |
Example request
{
"offers": [
{
"instance_descriptor": {
"lang_code": "EN",
"instance_name": "BeatsX black",
"category_id": "85",
"specification": [
{
"key": "brand",
"val": "Beats"
},
{
"key": "colour",
"val": "black"
},
{
"key": "connection_type",
"val": "Bluetooth"
},
{
"key": "connectors",
"val": "USB-C"
},
{
"key": "connectivity",
"val": "Bluetooth"
},
{
"key": "headphone_type",
"val": "Overear"
},
{
"key": "no_template_key",
"val": "random information"
}
],
"hints": {
"mpn": "MTH52ZM/A"
}
},
"sku": "Beats_x_bl_A",
"reference_price": "200",
"reference_currency_code": "EUR",
"stock": 0,
"grading": "A",
"shipping_profile_id": "2341",
"warranty": "M12",
"taxation": "GROSS",
"create_market_prices": [
{
"market_code": "fr",
"currency_code": "EUR",
"price": "82.00",
"min_price": "72.00"
}
],
"battery_condition": null
}
]
}
Prices can be defined in any of the supported currencies returned by the CurrencyService/ListCurrencies endpoint. Shipping costs have to be set within your shipping profiles.
The reference prices are the default prices used for all markets if you don’t specify any market offers. They are automatically converted into the respective market's currency if it doesn't match the offer price's currency and we have a localized site for it. The reference_price is only a reference and may be increased by refurbed due to dynamic pricing according to the merchant guide.
If you set a reference_min_price this price will be taken into consideration when calculating the BuyBox and your price could be lowered until your reference_min_price if that would make you win the BuyBox.
When creating an offer you can already create_market_prices by adding the market_code, price, currency_code, and optionally also a market-specific min_price per country if you want to set different prices in the countries you are selling in. Refer to the market offers article for more detail.
💡Learn more: Minimum Price Feature - How does it work and what are the main benefits?
If your account has been granted permission to sell devices with new battery, you will be able to create such offers directly by providing the battery_condition field in the payload. Creating offers with this attribute is only possible for certain product categories, your account manager can tell you which are eligible. Omitting the field will result in the value UNSPECIFIED. Offers with value UNSPECIFIED are treated like offers with the value OPTIMAL. So you would only need to create offers with value NEW to sell devices with new batteries.
You can use identifier matching (GTIN or MPN) like you would do with creating regular offers.
Resolution of your Listing Request
Once you sent your Listing Requests, they will immediately show up in the seller interface, if matching was possible as a valid offer with state OK and assigned instance_id. If not matchable or non-existing product the Listing Request will apper with state SUBMITTED waiting in a queue for the initial matching. If it cannot be matched automatically by our system, the state will transist to PENDING_REVIEW and awaiting manual action from refurbed’s team.
Once in review, refurbed can either resolve your request, which will create the offer and set state to OK, or reject your request due to various reasons, e.g.: device is not CE compliant, device is too old, not enough/unclear product data was provided. Refurbed will expose the Listing Request states in ListOffers as well as provide a rejection category and message (additional free text):
| rejection category | description |
|---|---|
| MISSING_REQUIREMENTS | Some of the mandatory parameters to determine what product the offer describes are missing |
| CONFIGURATION_DOES_NOT_EXIST | Product configuration does not exist as per manufacturer specification |
| CONFIGURATION_NOT_ALLOWED | Product described is not allowed to be sold due to platform rules |
| CONFIGURATION_NO_LONGER_SOLD | Product no longer allowed on the platform |
| NOT_ALLOWED_OFFER_PROPERTY | Offer request contained property that is not permitted for this category (e.g. battery) |
While some rejection reasons mark the end for you Listing Request, missing requirements or unclear data problems can be resolved by resubmitting your listing request with the same offer data, but corrected data in the specifications. This will retrigger the resolution process.