Listing schema

The header block on the PDP and the card.

Gallery images plus optional showcase videos. Through the bulk JSON importer we fetch every images[].src URL server-side and re-store it under your Blob prefix; through the editor uploader you upload bytes directly. Videos are stored as YouTube references and embedded on the PDP, we never download the video file.

A listing has exactly one transaction type, set by transactionType (purchase, rental, or lease), and its pricing carries only the matching block, a listing never holds buy + rent + lease at once. To offer the same robot another way (buy and rent, or new and pre-owned), create a separate listing; siblings share one stock pool. Money is integer cents (Stripe convention) on the wire; in the editor you type whole dollars or euros only, never a cent fraction, so every amount you enter is stored as a multiple of 100.

Optional, internal-only. Sellers see these; buyers never do. SKU is your reference; pool.capacity gates the listing’s visibility when set.

Condition is a field, not a separate listing type. grade: "new" (the default) is a fungible item sold from stock; grade: "pre_owned" is one specific used unit with its own history. Condition only matters for a purchase, when you rent or lease, the buyer gets an outcome, not a particular unit, so it isn’t shown.

A pre-owned listing is a single physical unit: pool is forced to null and the listing is removed once sold. The detail fields below are all seller-asserted; the “verified provenance” badge is earned separately from Botsdex-witnessed on-platform history, never self-declared.

workplaces is a string[] of where the robot can work, the cross-cutting search axis. Required: at least one. Seeded from your jobs’ defaults in the editor, then adjust to match reality.

Accepted values (extensible): home, office, hotel, restaurant, bar, cafe, hospital, care_home, pharmacy, retail, supermarket, mall, warehouse, port, factory, airport, transit_hub, gym, school, laboratory, stadium, sports_field, golf_course, convention_center, museum, theme_park, parking_lot, data_center, apartment_building, yard, pool, construction_site, farm, greenhouse, fish_farm, street_sidewalk, park, beach, solar_farm, wind_farm, power_plant.

Two facts that place the robot on the automation grid. Botsdex derives the buyer-facing archetype badge from them; you don’t set the badge directly.

Shared physical specs. All optional; the listing page renders only what is set.

If your listing is linked to a catalog model, specs you leave blank are filled in from the catalog, so you do not have to retype a robot’s height and weight that we already hold. Those rows show in the editor as read-only, with a note saying where the number came from. Clearing a field is not a way to state zero: a blank inherits.

You are never stuck with our number. Use my own value takes the row over for this listing, instantly, and your figure wins from then on, because you have the actual unit in front of you. The listing page marks a row “seller-stated” when yours contradicts ours, so buyers can see whose figure they are reading. Report it as wrong is the other route: it asks us to fix the number for every seller of that robot, so a person checks it first. Use the first when your unit differs, the second when we are simply wrong.

If you requested a new model, the specs on your listing are what we review to build that model’s catalog entry. Values we keep become the starting point for every seller who lists the same robot after you, so a spec sheet link on the request is the fastest way through, and a guessed number is worth leaving blank.

Cross-job facts under attributes that are not physical specs. Each one powers a filter that appears on every job where it applies. Send the value, not the label.

Buyers never discover freight after they have paid. The product page shows the price for their country with shipping broken out as its own line, so your rate card has to cover everywhere you ship before the listing can go live.

A more specific region always wins. Price EU once and every member state is covered; add a DE row and German buyers get that instead. Where shipping is already inside your price, enter 0 and the buyer sees “Included”.

Price one robot, not one order. A buyer who orders three is charged three times your rate, because that is three crates leaving your dock. And your rate card is not a substitute for fulfillment.shipsTo: a buyer can only check out to a country that is in shipsTo and priced, so removing a region from shipsTo closes it even if an old rate row is still there.

Country of origin is yours to declare. It is where the units you are selling were manufactured, not where they ship from, and it prints on the customs line of the buyer’s invoice. We ask you rather than filling it in from the catalog because you are the exporter of record answerable for it, and because the same model is often built in more than one country. If you are not certain, leave it blank: the line is simply omitted, and an omitted line is better than a wrong one.

Your rate card is also published as structured data (offers.shippingDetails), so a search engine can show your delivery cost next to your price. That is why shipping stays a separate line rather than being folded into the listing price: your price keeps meaning the robot.

Returns are required too. returns must be present before you can publish, and windowDays: 0 (final sale) is a perfectly good answer for a machine that cannot be resold as new. The rule is not that you accept returns, it is that a buyer knows the terms before they pay rather than after.

Separately, the Botsdex Guarantee always applies and you cannot waive it: if a robot never arrives, arrives damaged, or is not the machine you listed, you refund it in full including freight both ways. For rentals and leases, the same protection covers the affected handoff or charge, and the reservation is released when a refund is confirmed. After a buyer messages you, they can start a structured resolution request. You have 48 hours to make an offer before Botsdex support steps in, and a person reviews the case before anything is decided. See the Seller Agreement for the full obligations.

Install requirements. Water-line and drain power the utility-hookup filter, so answering them is what puts your robot in front of a buyer filtering for a machine their site can actually take. In the editor this is Install & site requirements.

Both are worth answering even when the answer is no: “no plumbing needed” is a selling point on a machine buyers expect to need it. Leaving a question blank is not the same as answering no, and we never turn one into the other.

All buyer-facing. Shown on the PDP and used for ranking.

Optional rich content rendered on the product page.

Heads up: email addresses, phone numbers, and websites are automatically removed from all of these text fields (and the rest of your listing copy) on save and on import. Buyers contact you through Botsdex, so off-platform contact details are stripped rather than published.

Attach the jobs your robot can do under supportedJobs[]. Each entry is { jobSlug, primary, attributes }, where attributes holds that job’s fields below. The fields marked Required must be set to publish under that job. Send the value, not the label (send scrub, not “Scrub”).

workRate is { value, unit } with the unit fixed per job; it is your headline throughput number and powers the comparison and the throughput filter.

Job-specific filters are shown dynamically: a job filter appears once more than 2 listings carry its attribute (on a job page that is counted across the job’s catalog, on search across the current results), below that it cannot narrow anything. The general filters (operation, workplaces, price, brand, ships-to, autonomy) always show. A filter a buyer has applied is never hidden. Filling your job fields is what makes your robot show up under those filters.

Can’t find your job? Attach the catch-all jobSlug: other. It asks one required field, taskTags (short task phrases like “window cleaning”), and leans on the universal fields plus customAttributes until a real job category exists. Listings under it are searchable but not browsable: the “other” job has no category tile and its landing page is not indexed.

Your own key-value spec rows under customAttributes, the escape valve for details no universal or job field models yet. A drink-pouring robot whose template stops at beverageTypes can still say { "label": "Beverages", "value": "hot chocolate, boba" }. Buyers see each row as “Label: value” text under “Additional details” on the listing page.

A row can optionally say what its value is. Add "type": "number" with a unit and { "label": "Water tank", "value": "12", "unit": "l" } reads as a quantity; "type": "boolean" reads Yes/No. Typing is never required, and a row that declares a type its value cannot honour just falls back to plain text rather than being rejected. We store your value exactly as you send it, so nothing is rounded or reformatted behind your back.

Rows are searchable but not filterable: a buyer typing the text can find your listing, but custom rows never become a search filter (an open vocabulary would fragment the filters). Nor can a custom row take over a field we already have: label one “Payload” and it stays plain text, because the real Payload filter is built from specs. If an existing field covers your fact, use that field. A custom row that keeps appearing across listings is a candidate for promotion into a real field, which is how it earns a filter.

A complete floor-cleaning listing as a feed would submit it. Only seller-set fields, Botsdex builds search from these.