A field-sales app that queues up 200 price updates while an area is offline has exactly one moment to reconcile: the second a connection returns. Sending those 200 changes as 200 individual PUT requests turns a few kilobytes of actual data into 200 TCP connections, 200 authorization checks, and 200 independent chances for exactly one of them to time out and leave the sync half-done. An API that only offers one-resource-at-a-time endpoints is not wrong, but it is the wrong tool for this moment, and a client that has to reach for it anyway will build its own ad hoc batching on top of it — usually without the transactional guarantees the server could have offered directly.
Two related but distinct shapes solve this. A bulk operation applies one action to many resources selected by a filter — delete every order with status returned, mark every shipment in a warehouse as delayed. A batch operation submits a list of individual operations, often heterogeneous, to be processed together, with each item getting its own outcome. Both exist because many APIs price and throttle by request count rather than payload size, so collapsing N round trips into one is not a convenience, it is capacity a client can actually use.
Analogy🏏Cricket
🏏 Think of it like cricket: Rahul Dravid, running the National Cricket Academy, does not summon each of the twenty-five India A probables for a private net session on twenty-five separate days before a tour. He blocks one combined week where throwdown specialists, physios, and video analysts work through the whole squad together, because scheduling one player at a time would burn a month on logistics before a single ball is bowled with intent. The combined week is not one session pretending to be many — it still produces twenty-five individual reports, one per player, and a throwdown specialist who pulls a hamstring on day two still stops that one player's sessions without cancelling anyone else's. Just as Dravid's academy batches the squad's preparation into one coordinated block instead of twenty-five uncoordinated bookings, a bulk endpoint batches many client operations into one request instead of many uncoordinated round trips. Just as each player in that block still gets an individual outcome — fit, managed load, or held back — a well-designed batch endpoint still reports an individual result per item, not one verdict for the whole group. The insight is that batching operations together is about collapsing the coordination cost, not about collapsing the operations themselves into a single indivisible unit.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.