Serbia's biggest classifieds site, as one JSON API

The one the seller chose, per ad — KupujemProdajem lets a seller quote in EUR or in RSD, and both appear in the same result set. We measured furniture rows coming back as 7,899 RSD and 150 EUR side by side. So every row carries price together with price_currency, and the listing action also returns price_display, which is the exact string KupujemProdajem prints on the ad page ("8.500 €", "2.500 din"), so you can check our number against the source's own rendering. On 15 ads sampled across ten categories the two agreed 15 of 15, with zero mismatches. We do not convert anything: a converted price is our arithmetic, not the seller's offer.

Because those ads have no price, and a zero would be a lie. Across 300 sampled rows in ten categories, 227 carried a price and 73 did not: job posts, wanted ads where the poster is buying rather than selling, and ads where the seller asks you to enquire. KupujemProdajem writes a 0 into those, so the API returns null and puts the reason in price_kind — not_priced_job, not_priced_wanted or not_priced — alongside the site's own label ("Posao" for a job, "Kupujem" for a wanted ad). If you only want ads with a real number, set has_price: it narrowed a 4,595-ad control to 1,989.

Every filter we expose was measured against the same-run unfiltered control, and only the ones that moved the total are offered. Against a control of 4,595 ads (keywords telefon, category 23): location=1 (Belgrade) 2,842, a 100-200 EUR band 137, condition=new 481, condition=as-new 1,909, condition=used 1,956, condition=damaged 47, listing_type=sell 2,108, listing_type=buy 2,487, has_price 1,989, has_photo 4,565, exchange_only 128, immediate_available 1,249, group=489 (Apple iPhone) 721. Thirteen for thirteen. Two filters the site accepts but does not usefully apply are deliberately not exposed, because a handle that does nothing is worse than no handle. And an unknown condition or sort value is rejected with INVALID_PARAM rather than passed through, because the site would answer a typo with a convincing empty page.

All of them in a category search, and 20,000 in a keyword search. Measured both ways: category 743 reported 64,085 matching ads over 2,137 pages and page 2,137 really did serve the last 7 rows, with the site's own counter agreeing to the row. The keyword search keywords=iphone reported 20,000 over 667 pages, page 667 returned 19 rows and page 668 returned none — exactly 20,000 — while count for the same words said 84,726. So search returns total_results, total_capped and total_available, and you can see at a glance whether you are looking at the whole set. If you need past 20,000 on a keyword, add a category, a town or a price band and the ceiling stops mattering.

Thirty by default, and it is a real parameter, not a fixed page size: we measured 30, 60, 100, 120, 200 and 500 rows per page all honoured exactly, at roughly 59 KB, 118 KB, 193 KB, 231 KB, 384 KB and 956 KB of response. One search credit covers whichever you pick, so a bulk pull is cheaper at 200 or 500 and a UI feed is leaner at 30.

What the ad page itself shows, unmodified: the display name, whether the account is a person or a company, their town, the date they joined, their positive and negative review counts, whether their phone and their bank account are verified, their stated reply habit, their profile note, and — for company accounts — the Serbian tax (PIB) and registry (MBR) ids. On one sampled seller that was 1,326 reviews, 1,326 positive, 0 negative, a member since 2017-06-03, phone and bank account both verified. The seller block was present on 10 of 10 details we sampled. You can also pull every ad one seller has: pass their seller_id to search.

No. KupujemProdajem keeps the phone behind a separate click on its own site, and this API never asks for it and never returns it. What you do get is the site's own has_phone flag, so you know whether a phone exists on the ad without us going after it.

The full description instead of the snippet — 221 to 3,635 characters on the ads we sampled, with the site's bold tags and HTML entities already cleaned out — plus every photo at full size and as a 300x300 thumbnail (1 to 15 per ad in our sample), the ad status and its expiry date, courier-delivery and local-pickup availability, the paid-placement type, and the category-specific fields where they exist: ISBN for books, OEM code for parts, VIN, mileage and registration status for vehicles. Everything in the search row is in there too, and an ad id taken from search resolved to the same record 15 of 15 times.

Because the site only offers a condition where it makes sense. Property, jobs and services have no condition field at all, so it came back on 180 of 300 sampled rows and we return null rather than inventing "used". You do not have to guess which categories have it: the categories action returns a shows_condition flag (and a shows_exchange flag) per category, so you can tell before you filter.

Where the site publishes them, and we are honest about how often that is: the attributes array was filled on 4 of the 10 details we sampled — vehicles and property — and empty on most goods ads, where the detail lives in the free-text description instead. We return the empty array as an empty array. Mileage, VIN and registration status for vehicles come back as their own named fields regardless.

Yes, and on this site that is a real market rather than a rounding error: in a 4,595-ad control, 2,487 were wanted ads and 2,108 were offers. Set listing_type to buy to get only the wanted ads, sell for only the offers, or leave it off for both. Wanted ads carry no price by definition, and the API labels them not_priced_wanted instead of showing a zero.

You get NOT_FOUND with a message saying the ad is removed or never existed, never a blank success you have to interpret. A search that genuinely matches nothing is a different thing and is treated as one: ok with zero rows and total_results 0, because an empty answer is still an answer. We measured both — a dead id and a nonsense keyword — on two separate runs.

The categories action returns all 89 category ids with their names and kinds, so category needs no guessing. Town and sub-group are different, and we say so rather than implying a catalogue exists: KupujemProdajem publishes no public list of either, so location_id and group_id come back on every search row next to their names, and you take the id from there. Both filters are measured working — Belgrade narrowed a 4,595-ad control to 2,842, and the Apple iPhone sub-group to 721.

KupujemProdajem API is a ReefAPI endpoint group for serbia's biggest classifieds site as json: cars, flats for sale and to rent, phones, furniture, clothing, services and jobs, with the seller's own currency, review history and verification badges. It returns live JSON through POST requests under /kupujemprodajem/v1.