P
Patrick Fabre
## Problem
Strapi allows content editors to manually reorder relations using drag-and-drop in the Admin UI.
This creates a natural expectation that the order of those relations is meaningful content and can be consumed by applications through the API.
However, while Strapi persists and displays the editor-defined order in the Admin UI, there is currently no supported or reliable way to retrieve relations in that same order through REST or GraphQL APIs.
As a result:
  1. Editors spend time curating and ordering content.
  2. Strapi stores and restores that ordering in the Admin UI.
  3. Developers cannot reliably retrieve that ordering through the API.
This creates a disconnect between the editorial experience and the developer experience.
---
## Why this matters
The order of related content is often part of the content itself, not merely a presentation concern.
Common examples include:
  • Featured articles
  • Homepage content blocks
  • Product showcases
  • Learning paths
  • Curated collections
  • Navigation structures
  • Related content sections
  • Recommended products or resources
In these cases, editors intentionally arrange items in a specific order.
When a CMS exposes drag-and-drop ordering, users reasonably expect that ordering to be available to API consumers.
---
## Existing workarounds
Current workarounds include:
  • Creating explicit sort fields on related entities
  • Creating wrapper content types
  • Using repeatable components instead of relations
  • Maintaining ordering logic outside the relation itself
While these approaches can work, they duplicate functionality already available in the Admin UI and add unnecessary complexity to content modeling.
---
## Why this feels like a product gap
The key point is that Strapi already supports editorial ordering:
  • Editors can reorder relations.
  • The order is persisted.
  • The order is restored when editing content later.
The information already exists.
The missing capability is providing a supported way for developers to retrieve that editor-defined order through the API.
This is not a request for a completely new editorial feature. The editorial workflow already exists.
---
## Community history
This topic has been raised repeatedly over multiple years and across multiple major versions of Strapi.
GitHub issues:
  • #2616 (2019) — Relation order not preserved
  • #6010 (2020) — GraphQL relation ordering concerns
  • #16961 (2023) — Relation ordering inconsistencies in API responses
  • #24212 (2025) — Closed as "will not fix"
  • #25582 (2026) — Similar concerns around relation ordering
Forum discussions:
The recurrence of this topic suggests a mismatch between user expectations and the current platform behavior.
Many users appear to assume that if a relation can be ordered by an editor, that order can also be retrieved by applications.
---
## Requested enhancement
Provide a supported way to retrieve relations in the exact order configured by editors.
Possible implementations could include:
### Option 1
Return relations in editor-defined order by default.
### Option 2
Expose the stored relation order through a dedicated field.
### Option 3
Provide an explicit query parameter or API option that requests editor-defined ordering.
The specific implementation is less important than providing a supported and documented mechanism.
---
## Expected behavior
If an editor manually reorders relations in the Admin UI and saves the entry, developers should have a supported way to retrieve those relations in the same order through REST and GraphQL APIs.
Editor-defined order is content and should be retrievable.