# Alternative to CAT shards API **URL:** \ **Category:** Elasticsearch\ **Created:** [November 23, 2025, 11:13am UTC](https://discuss.elastic.co/t/alternative-to-cat-shards-api/383600 "2025-11-23T11:13:54Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![pingo](https://avatars.discourse-cdn.com/v4/letter/p/3ec8ea/32.png) [@pingo](https://discuss.elastic.co/u/pingo)\ **Post date:** [November 23, 2025, 11:13am UTC](https://discuss.elastic.co/t/alternative-to-cat-shards-api/383600/1 "2025-11-23T11:13:54Z")
Hey! All of the CAT APIs come with this disclaimer: > **IMPORTANT: cat APIs are only intended for human consumption using the command line or Kibana console. They are not intended for use by applications.** Is there an alternative API, intended for use by applications, that can return the index name, shard number, shard state, prirep and the node name (not the node ID)? As far as I can tell, getting all this would require calling multiple APIs (e.g. `/_stats` and `/_nodes`) and cross-referencing the node ID, but I would like to call just a single API, if possible, in order to minimise the load on the cluster. I thought the cluster state API could be the way to go but that has a similar disclaimer: > **WARNING: The response is a representation of an internal data structure. Its format is not subject to the same compatibility guarantees as other more stable APIs and may change from version to version. Do not query this API using external monitoring tools. Instead, obtain the information you require using other more stable cluster APIs.** ---
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [November 23, 2025, 2:19pm UTC](https://discuss.elastic.co/t/alternative-to-cat-shards-api/383600/2 "2025-11-23T14:19:23Z")
Interesting question, I hope someone answers. I’d always considered the \_cat APIs as more aimed at administrators of the elasticsearch system itself, rather than applications/developers. Out of curiosity, what is your use case where your application needs to know (eg) if a specific shard from a specific index is a replica or a primary shard? What would your _application_ do with that information? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [November 23, 2025, 6:51pm UTC](https://discuss.elastic.co/t/alternative-to-cat-shards-api/383600/3 "2025-11-23T18:51:08Z")
> [@pingo](#): > > Is there an alternative API Short answer: no. You need to cross-reference `GET _stats` and `GET _nodes`. That’s effectively all that `GET _cat/shards` does anyway so the load will be the same. If you really want to trim things down then `GET _nodes/_all/info/none?filter_path=nodes.*.name` is the most efficient way I can think of to get a mapping from node IDs to node names. You can cache this result too, unless you’re doing something weird that would result in nodes’ names changing (in which case: don’t do that!). `GET _stats` is the heavy one but it has [many options](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-stats) for cutting out bits you don’t need. But also yeah what @RainTown said: what are you actually doing with this information? It’s rare to need it at the application level. ---
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [November 25, 2025, 12:13pm UTC](https://discuss.elastic.co/t/alternative-to-cat-shards-api/383600/4 "2025-11-25T12:13:21Z")
> [@DavidTurner](#): > > But also yeah what @RainTown said: what are you actually doing with this information? It’s rare to need it at the application level. @pingo - I am still curious. It’s possible, if you share what your idea is/was, that there are other ways to accomplish same thing. Or even that it may a bad idea, and you should not be doing it, via `_cat` API or any other way, and it would surely be better to know that?