Reorder rules
The whole order in one call, because a rule list only means anything in order.
Runs the real call against your workspace, with your own key.
POST /rules/reorder
The whole order in one call, because a rule list only means anything in order.
Example
Needs rules:write. The body names EVERY rule on the connection, in the order you want them evaluated. Returns the full list in its new order.
curl -X POST "$OE/rules/reorder" -H "$AUTH" -H "Content-Type: application/json" \ -d '{ "ruleIds": ["rul_7f3a1c94…", "rul_2b81de07…", "rul_c40a95f2…"] }'{ "object": "list", "data": [ { "object": "rule", "id": "rul_7f3a1c94…", "name": "Receipts to their own label", "position": 0 }, { "object": "rule", "id": "rul_2b81de07…", "name": "Newsletters after hours", "position": 1 }, { "object": "rule", "id": "rul_c40a95f2…", "name": "Anything from the old domain", "position": 2 } ], "hasMore": false, "nextCursor": null}A partial list is incomplete_order, a 422, and nothing moves. Accepting one would mean inventing positions for the rules you left out, and where those landed relative to the ones you named would be our guess about your mailbox rather than your instruction.
Idempotent by construction: the body names the whole order, so sending it twice lands in the same place. It is safe to retry and safe to run from a script that does not know the current order.
Every position is rewritten in one statement inside one transaction, so there is no moment at which two rules share a position or the list is half-renumbered.
Order is not cosmetic. It decides which of two rules names the folder a message ends up in, and where a stopProcessing rule cuts the list off.