Replacing nightly file drops with an integration that holds up

Inbound storefront orders → API page (OData v4 / JSON). A custom API page exposes a clean, versioned contract with only the fields the storefront needs, and returns the created record including the order number, which satisfies the synchronous confirmation requirement. Reading and writing through an API page respects AL validation and triggers; exposing a UI page as SOAP does not give you a controlled contract and couples the integration to page layout.

Outbound status to the warehouse → webhook subscription (or Service Bus / Event Grid) instead of polling. Polling every 30 seconds from two systems against a 20-per-minute peak is wasted requests, hits service protection limits, and still gives up to 30 seconds of latency. A webhook notifies the subscriber when the entity changes; a message broker is the better choice when the warehouse needs guaranteed delivery and replay.

Why not the proposed SOAP page 42: it exposes far more surface than required, it is painful to evolve, and it can be broken by a UI change. Nightly files are the opposite failure - correct structure, wrong latency and no error visibility.

Judgment point: choose the interface from the latency requirement and the shape of the data exchange, not from what is easiest to switch on.

Replace the shared superuser key with OAuth 2.0 client-credentials against Microsoft Entra ID, one application registration per external system, and a dedicated integration user in Business Central.

• Least privilege: the integration user gets a custom permission set covering only the tables the interface touches. Superuser defeats every other security control and makes audit trails meaningless.
• No static keys in config files: client secrets or certificates live in a managed secret store and are rotated on a schedule. A key that never expires is a permanent credential leak waiting to happen.
• Environment separation: the sandbox and production use different registrations and different users, so a misconfigured test cannot write to production. The same rule applies per company.
• Auditability: every write through the API carries the integration user's identity, so a bad batch can be traced to an interface and time window instead of to "someone."

Judgment point: the security flaw and the integration design are separate findings. Fix both, and be explicit that the secret rotation schedule is part of the design rather than an operational afterthought.

Assume the network, the warehouse system and Business Central will each fail independently.

• Retries with backoff: retry transient failures (timeouts, 5xx) with exponential backoff and jitter; do not retry immediately in a tight loop. Respect the Retry-After header on throttling responses and stay within service protection limits rather than assuming unlimited throughput.
• Idempotency: the storefront request carries a unique external document reference. The API maps it to a Business Central order and returns the existing one if it has already been created, so a retried request cannot create a second order.
• Outbound durability: a webhook that fails once should not lose the event. Either retry with a dead-letter queue, or use a broker with a durable subscription so the warehouse can replay.
• Batch and split: for bulk operations use $batch or chunk the payload rather than a single long-running call; a 20-minute transaction is a lock, not an integration.
• Observability: log correlation IDs and emit telemetry on integration failures; alert on the dead-letter queue depth, not on a user complaint.
• Reconciliation: a daily count-and-total comparison between systems catches the failures that retries silently swallowed.

Judgment point: idempotency plus a durable failure path is what separates an integration from a script. The nightly flat file had neither.