The “Single Threaded API” Trap: How Unbatched OData Requests Crush BC Throughput
Auditing an enterprise integration between a custom React store front and Business Central SaaS resulted to an interesting discovery, every time a customer placed a multi-line order, the middleware made separate HTTP POST requests: one for the order header, and one for each individual order line.
Result? 8 – 12 seconds per checkout.
Not from slow SQL, but from the middle tier drowning in:
HTTP handshake overhead
Transaction isolation locks
429 “Too Many Requests” throttling
The bottleneck wasn’t the query, it was the architecture.
⚠️ The Problem: The API round trip explosion.
When external systems integrate with Business Central web services using standard REST/OData endpoints, issuing individual HTTP calls for related sub-entities creates an O(n) network round-trip penalty.
Each individual HTTP call incurs TLS handshake negotiation, authentication verification, and NST session initialization overhead. More dangerously, writing lines sequentially across separate HTTP calls leaves open write transactions, risking lock contention on master tables like Item and Customer.
🛠️ The Fix: OData v4 $Batch Payload Processing
Stop making sequential API calls for master-child records. Leverage OData v4 $batch requests to wrap the header, all line items, and final commit requests into a single HTTP payload execution context.
By submitting a changeset inside a $batch boundary, Business Central executes the entire payload in a single, atomic server-side transaction pass, reducing network overhead from n round trips down to exactly 1.
Technical Grounding:
➡️ SaaS Available: Yes (Full support for OData v4 $batch).
➡️ Runtime/Upgrade: Runtime.
➡️ Bypasses Triggers: No, standard table/page API triggers fire.
Why It Matters
✅ Sub-Second Throughput: Drops external integration processing time by up to 90% by replacing dozens of HTTP round-trips with a single network socket connection.
✅ Atomic Integrity: Guarantees that if line item 5 fails validation, the entire order header rolls back automatically, eliminating orphan header records in production.
✅ Throttling Immunity: Drastically lowers request counts against your tenant’s operational limits, preventing “429 Too Many Requests” API lockouts during sales spikes.
☣️ The Trap
If one request inside an OData $batch changeset fails, the entire batch rolls back; always ensure your middleware logs individual item error payloads returned in the multi status HTTP 200/207 batch response.
💡 The Bottom Line
Stop treating Business Central APIs like a series of single file operations. Group your transactional writes into $batch payloads and let the middle tier process them in one clean pass.