In a Postman collection file, what determines the order of the entries inside a folder?

## Position is the only ordering signal A **Postman collection** keeps everything it contains in one array named `item`. The order of those entries is their **position in that array** — the first object is first, the second is second, and that is the entire mechanism. The document carries no `order` key, no numeric index property on an entry, and no recorded sort criterion sitting beside the entries to say what the order was meant to be. Ordering is therefore a property of the JSON structure, not of any field you can read off a single entry. You cannot look at one entry and learn where it comes; you can only see where it sits. ## Ordering applies once per array, not once per file Because a folder is itself an entry that carries its own `item` array, the rule is applied at every level of the tree: - A folder occupies **one** position in its parent's array. - Everything inside that folder is ordered by its own nested `item` array, independently of entries elsewhere. - Two entries in different folders have no relative order of their own; the only order between them is the one implied by their folders' positions. - Inserting an entry anywhere but the end shifts the position of every entry after it, though none of those entries changed. - An empty folder still occupies a position. Emptiness is not absence. The result is an **ordered tree**: sibling order is defined at every level, and reading the document in order is a depth-first pass over it. ## What the document actually records about order | Ordering signal | Present in the collection document? | |---|---| | Position within an `item` array | Yes — this is the mechanism | | An `order` key listing entry identifiers | No | | A numeric index or sequence field per entry | No | | A recorded sort criterion, such as by `name` | No | | Nesting, which selects *which* array a position is read in | Yes | The absent rows matter more than the present ones, because they are exactly what people assume is there. When someone asks what order a set of entries is in, the honest answer is: read the array. ## Consequences for editing, diffing and tooling 1. **Reordering is a move, not an edit.** To change the order you move the JSON object; no field value flips, and no attribute records that you did it. 2. **A diff of a reorder can be large and misleading.** It shows deletions and insertions even though no request changed. Reviewing it means confirming the set of entries is unchanged and then reading the new sequence deliberately. 3. **Any tool that rewrites the array can rewrite behaviour.** A formatter that sorts arrays, a merge resolved by concatenating both sides, or a regeneration from another source all change declared order without touching a value. 4. **A generated file inherits the generator's order**, whatever that happens to be, and the document preserves no separate intent a later tool could restore. ## Reading order in practice Given a folder that holds a sign-in request followed by a folder of profile requests followed by a sign-out request, the sequence is exactly that: sign-in, then everything in the profile folder in its own array order, then sign-out. To move sign-out earlier you move its object earlier. To move one profile request out of the group you move its object out of the nested array — which also changes its ancestors, not just its place. ## Common mistakes - Hunting for an `order` field and concluding the document is under-specified when it simply orders by position. - Believing a client sorts entries for display, so the file's order does not matter. - Treating a pure reorder as a cosmetic diff that needs no review. - Assuming two entries in different folders have a defined order relative to each other. - Prefixing names with numbers to "fix" the order — names order nothing here; positions already did.