Business Central Web Service Performance: Fast, Resilient API Patterns

Business Central integration performance is shared between the endpoint and the client. A carefully written API page can still fail under a consumer that requests every field, ignores paging, retries writes without idempotency, or creates unbounded parallel calls. A disciplined client cannot compensate for heavy AL triggers or an endpoint built from a user-interface page.

Microsoft recommends REST API web services for new Business Central integrations. The API stack is optimized for this scenario. Microsoft states that SOAP is replaced by OData V4 and that support for SOAP endpoints will be removed in a later release, and that access keys for web-service authentication are not supported in Business Central online, where OAuth 2.0 is required instead.

Use the right endpoint type

Start with Microsoft's standard API v2.0. When a custom contract is necessary, use an AL API page or API query. Avoid publishing a normal UI page as a web service: its triggers, calculated fields, and FactBoxes can execute work that the consumer never receives.

API queries are useful for read-only projections. API pages support create, read, update, and delete behavior. Keep each endpoint focused on one entity or operation boundary.

Bound every read

A client should select the fields it needs, filter on supported indexed dimensions, and follow server-provided paging. Avoid "download everything since the beginning" on every run. Persist a durable watermark or change-tracking strategy appropriate to the business contract and include a reconciliation path for missed or changed records.

Do not promise an exact page size or throttling limit unless the current Microsoft documentation and tenant behavior support it. Consumers should follow continuation information and handle throttling as a normal cloud condition.

Keep endpoint AL lean

Microsoft's performance guidance identifies costly endpoint patterns:

• standard UI pages with heavy OnAfterGetRecord logic or FactBoxes;
• calculated fields that execute for every returned row;
• large temporary-table sources that make paging expensive;
• aggregation on API queries when detailed rows are required;
• parallel child inserts that contend on the same parent and integration records.

Use physical storage for values that are expensive to reconstruct and legitimately belong to the entity, but do not denormalize without an ownership and update strategy.

Design writes for retry and concurrency

Web services are stateless. If a request times out, the client may not know whether Business Central committed the operation. Use a stable external ID or integration-ledger key so a retry finds the prior result instead of creating a duplicate.

Honor optimistic concurrency and avoid blind overwrite. For related writes, use a supported batch or sequence where atomicity and ordering matter. Do not run many parallel calls that update the same document header or parent record.

Separate acceptance from processing

For long-running work, consider accepting a validated command into a durable queue and returning a correlation identifier. A job queue can perform the business operation with controlled retries and status visibility. This is appropriate only when the business process permits asynchronous completion; a required real-time validation must remain synchronous.

Use OAuth and least privilege

Use Microsoft Entra ID/OAuth 2.0 for Business Central online. Scope the application registration and Business Central permission sets to the endpoints and records needed. Rotate credentials through an approved secret process and never log tokens or authorization headers.

Instrument both sides

Business Central telemetry records incoming web-service execution and status information. The client should record correlation ID, endpoint, operation, duration, result category, retry count, and checkpoint without logging sensitive payloads. Together, those signals show whether time was spent in the caller, network, Business Central endpoint, database, or downstream processing.

Consumer resilience checklist

1. Use bounded timeouts and distinguish transient from permanent failures.
2. Retry only operations that are safe or protected by idempotency.
3. Use backoff for throttling and service failures.
4. Persist checkpoints after durable success, not request submission.
5. Quarantine poison records with a reason and owner.
6. Reconcile source and target counts/business totals.
7. Alert on sustained failure or lag, not every individual retry.

Baseline volume, latency, and error rate before changing the endpoint or client. Compare the same workload after the change so an apparent improvement is supported by evidence rather than a quieter test period.

Bitta Apps designs Business Central integrations, tunes custom endpoints through AL development, and operates monitoring and reconciliation through ongoing support.