Batch REST API (/api/now/v1/batch): Is sub-request execution order guaranteed?

[BineshJ]

Hi all,

I’m using the Batch API (POST /api/now/v1/batch) and need to know how sub-requests within a single batch are ordered. The official documentation doesn’t answer this, so I’d like to confirm it before relying on it.

What I found

• The Batch API page in the API Reference documents batch_request_id and rest_requests (id, method, url, headers, body, exclude_response_headers). It doesn’t mention enforce_order or say anything about execution order.
• The docs do say the Batch API is not intended for parallel transaction processing, and that unprocessed items are returned in unserviced_requests when a size or time limit is hit.
• ServiceNow’s patent for this feature (US 2021/0042176 A1, “Batch representational state transfer (REST) application programming interface (API)”) describes an enforce_order field in the request opening, with a default of false. It says the server may reorder items so the less computationally intensive ones run first, and that setting enforce_order to true makes the server execute items only in the submitted order.
• A community article on the batch endpoint shows a sample payload with "enforce_order": false, but doesn’t explain it.

My questions

1. Does the Batch API execute sub-requests in the order they appear in rest_requests?
2. Is enforce_order a supported parameter in the shipped product? If so, does setting it to true guarantee sequential execution in the submitted order, and in which releases?
3. When enforce_order is false or omitted, can the platform reorder sub-requests as the patent describes, or does it always run them in submitted order in practice?
4. Does setting enforce_order: true have a performance impact? Since it forces strict ordering, does it disable any instance-side optimization (such as running cheaper items first) that would otherwise apply, and is the difference measurable in practice compared with the default behavior?
5. If a sub-request fails (for example a 4xx/5xx or an ACL denial) with enforce_order: true, are the remaining items still executed?
6. If the time or size limit is hit, are the IDs in unserviced_requests always the items at the end of the submitted list, or the last ones in the platform’s execution order?

Thanks in advance. Any pointer to official documentation or a Support KB article on this would help too.