# API: Include marker attributes in search results?

**URL:** <https://streetart.community/t/api-include-marker-attributes-in-search-results/3802>\
**Category:** Support\
**Created:** [October 18, 2026, 5:57am UTC](https://streetart.community/t/api-include-marker-attributes-in-search-results/3802 "2026-10-18T05:57:31Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tony](https://streetart.community/user_avatar/streetart.community/tony/32/3086_2.png) [@Tony](https://streetart.community/u/Tony)\
**Post date:** [October 18, 2026, 5:57am UTC](https://streetart.community/t/api-include-marker-attributes-in-search-results/3802/1 "2026-10-18T05:57:31Z")

</div>

I wanted to use the API to add a way of browsing artworks in a city by date (and to spot anything that’s currently missing that, or has an implausible value). But currently the attributes of an artwork aren’t returned from the search results: only from `/api/markers/{markerId}`

This means I need to hit that API call once per artwork in a location, which is obviously doable, but presumably not great for the server, even if I cache the results and only refetch if lastUpdated changes. I’m guessing the search API omits these largely just to avoid transferring lots of extra unnecessary data in the default case? If so perhaps there could be an extra query parameter to include them in the results?

---

<div class="post-metadata">

**Author:** ![thomas](https://streetart.community/user_avatar/streetart.community/thomas/32/810_2.png) [@thomas](https://streetart.community/u/thomas)\
**Post date:** [October 19, 2026, 4:03pm UTC](https://streetart.community/t/api-include-marker-attributes-in-search-results/3802/2 "2026-10-19T16:03:46Z")

</div>

Hi Tony, good shout! Rather than adding an extra parameter, we’ve made it the default: every item in `/api/markers/search` now has exactly the same fields as `GET /api/markers/{markerId}`, so that includes `attributes` and `images` too.

That means you can grab all the artworks in a city in a few paged search requests, without a call per marker. The developer docs have been updated to match.

Would love to see the browse-by-date view once you’ve built it, and let us know if anything looks off!

---

<div class="post-metadata">

**Author:** ![Tony](https://streetart.community/user_avatar/streetart.community/tony/32/3086_2.png) [@Tony](https://streetart.community/u/Tony)\
**Post date:** [October 19, 2026, 6:18pm UTC](https://streetart.community/t/api-include-marker-attributes-in-search-results/3802/3 "2026-10-19T18:18:26Z")

</div>

@thomas woot! Thank you! That’s now live: if you click the little clock in the headerbar at [https://streetart.tonybowden.com/](https://streetart.tonybowden.com/) it’ll show you the artworks in your current city ordered by date, or you can go directly to an individual city by tweaking the URL like [/timeline.html?city=bristol](https://streetart.tonybowden.com/timeline.html?city=bristol) as long as you’re already logged in

I’m assuming all the artworks dated 1970-01-01 were a migration at some point with an awkward default? Is it worth bulk removing those values at some point?

---

<div class="post-metadata">

**Author:** ![thomas](https://streetart.community/user_avatar/streetart.community/thomas/32/810_2.png) [@thomas](https://streetart.community/u/thomas)\
**Post date:** [October 19, 2026, 6:39pm UTC](https://streetart.community/t/api-include-marker-attributes-in-search-results/3802/4 "2026-10-19T18:39:55Z")

</div>

Cool!

Oh yes, let me look at why those show like that.

---

<div class="post-metadata">

**Author:** ![thomas](https://streetart.community/user_avatar/streetart.community/thomas/32/810_2.png) [@thomas](https://streetart.community/u/thomas)\
**Post date:** [October 23, 2026, 10:25am UTC](https://streetart.community/t/api-include-marker-attributes-in-search-results/3802/6 "2026-10-23T10:25:24Z")

</div>

These should be fixed now, I’ve just updated a few thousand markers that had their date set to 1970 (and one that was set to the year 1019 for some reason haha).
