# \[OCS API\] Wrong downloads count for an item

**URL:** https://forum.opendesktop.org/t/ocs-api-wrong-downloads-count-for-an-item/21080
**Category:** Opendesktop.org - Your Libre Cloud Services
**Created:** [November 12, 2024, 6:36am UTC](https://forum.opendesktop.org/t/ocs-api-wrong-downloads-count-for-an-item/21080 "2024-11-12T06:36:46Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![emvaized](https://forum.opendesktop.org/user_avatar/forum.opendesktop.org/emvaized/32/117489_2.png) [@emvaized](https://forum.opendesktop.org/u/emvaized)
#### Post date: [November 12, 2024, 6:36am UTC](https://forum.opendesktop.org/t/ocs-api-wrong-downloads-count-for-an-item/21080/1 "2024-11-12T06:36:46Z")

</div>

I’m trying to use OSC API to get the downloads count of my item published on the Pling store.

The item id is: `1875687`

I’m using the following url:  
`https://api.pling.com/ocs/v1/content/data/1875687?format=json`

In response I get “5197” downloads:  
 ![screenshot 1](https://forum.opendesktop.org/uploads/default/original/3X/b/7/b7989377b8bd5a40171c6a01378e5071f14f39cf.png)

But the Pling store page shows the downloads count “4315” for the last and only available file:  
 ![screenshot 2](https://forum.opendesktop.org/uploads/default/original/3X/5/a/5ac385680571ef14f0845b38c2f91e32e4a9aec9.png)

At first I assumed that the API response counts all-time downloads including the archived files, but the returned number doesn’t correspond. I checked a few other items from the Pling store, and the returned downloads value always doesn’t correspond, despite all the other information being correct (publication name, version number, comments count, etc).

---

<div class="post-metadata">

### Author: ![dschinn-de](https://forum.opendesktop.org/user_avatar/forum.opendesktop.org/dschinn-de/32/117874_2.png) [@dschinn-de](https://forum.opendesktop.org/u/dschinn-de)
#### Post date: [November 14, 2024, 7:21am UTC](https://forum.opendesktop.org/t/ocs-api-wrong-downloads-count-for-an-item/21080/2 "2024-11-14T07:21:18Z")

</div>

We are looking at this and correcting it if necessary, as we are currently working on the API.