INTEGRATION · BUSINESS CENTRAL API · RELIABILITY

Business Central API Rate Limits & Throttling: Complete Guide

A production integration should not assume that every API request will succeed immediately. Business Central online uses rate limits and throttling to protect shared resources. This guide explains HTTP 429, transient errors, Retry-After, retry strategies, batching, queues and practical AL integration patterns.

1. What Are API Rate Limits?

Rate limits restrict how aggressively a client can use a web service. They help protect shared cloud resources such as CPU, memory and I/O so one client does not consume an unreasonable share of resources.

When Business Central throttles a request because API request limits have been exceeded, the client can receive HTTP 429 Too Many Requests.

Key idea: a 429 is not usually a signal to send the same request immediately again. Your integration should slow down, wait, and retry using a controlled strategy.

2. What Happens When Throttling Occurs?

Business Central documentation recommends retry logic with a cool-off period. Possible strategies include regular intervals, incremental intervals, exponential backoff and randomization. For some transient responses, the service may also provide a Retry-After header that your client should respect.

Status	Meaning	Typical response
429	Too Many Requests	Slow down and retry with backoff/cool-off.
503	Service Temporarily Unavailable	Retry using a controlled delay.
504	Gateway Timeout	Refactor/split long-running work rather than simply repeating a huge request.
502	Bad Gateway	Retry when appropriate and respect Retry-After when supplied.

3. Why Integrations Get Throttled

Too many requests in a short period.
Unnecessary polling of large collections.
Large synchronization jobs that issue one request per record.
High parallelism without controlling concurrency.
Repeated immediate retries after failures.
Queries that return more data than the integration actually needs.

4. Retry-After Comes First

When a response contains a Retry-After header, use the server-provided delay rather than guessing a shorter interval.

if StatusCode = 429 then begin // Read Retry-After when provided // Wait for the recommended delay // Retry the request end;

If throttling continues, use exponential backoff and a sensible maximum retry count.

5. Exponential Backoff

Exponential backoff increases the delay after each failed attempt. A simplified sequence might be:

Attempt 1 → wait 1 second Attempt 2 → wait 2 seconds Attempt 3 → wait 4 seconds Attempt 4 → wait 8 seconds ... Stop after a defined retry limit

The exact values should be chosen for your integration rather than copied blindly. Adding jitter/randomization can also reduce synchronized retry spikes when many workers fail at the same time.

6. Never Retry Immediately in a Tight Loop

This is a common integration mistake:

while not Success do begin HttpClient.Get(Url, Response); end;

If the server is throttling, this pattern can make the situation worse. Always introduce controlled delay and a retry limit.

7. Reduce the Number of API Calls

The best retry strategy is often the one you never need because the integration makes fewer calls.

Use filters to retrieve only required records.
Use $select to reduce payloads where supported.
Use pagination correctly.
Use batch operations when appropriate.
Use deep inserts where they fit the API scenario.
Use webhooks instead of frequent polling when change notifications are available.

8. Polling vs Webhooks

A polling integration repeatedly asks whether something changed. A webhook-based design lets Business Central notify the subscriber when supported entities change.

For synchronization scenarios, webhooks can reduce unnecessary repeated reads and improve responsiveness.

9. Batching and Concurrency

Batching can reduce the number of HTTP round trips, but a batch that is too large can increase processing time and timeout risk. Likewise, sending many requests concurrently can create traffic spikes.

Production rule: more parallel requests do not automatically mean more throughput. Measure the system and control concurrency according to the workload.

10. Handling 504 Gateway Timeout

Business Central documentation states that request execution is limited to 10 minutes; a request that cannot complete within that limit can return 504 Gateway Timeout. The solution is normally to split long-running work into smaller requests rather than retrying the same oversized request repeatedly.

11. Queue-Based Integration Pattern

A queue is a useful way to flatten traffic spikes. Instead of firing every synchronization operation immediately, the application places work into a queue and processes it at a controlled rate.

Business Central ↓ Integration API / Queue ↓ Worker ↓ API request ↓ 429? → delay → retry 503? → delay → retry Success → mark complete Permanent failure → log / dead-letter

12. HttpClient in AL

When AL calls an external service through HttpClient, the Business Central server waits for the outgoing call to complete. Interactive sessions can therefore be affected by slow external services.

HttpClient.Get(RequestUrl, Response); StatusCode := Response.HttpStatusCode(); if Response.IsSuccessStatusCode() then begin // Process response end else begin // Log status // Decide whether the error is retryable end;

For long-running or recurring integrations, background processing and controlled retry design are generally preferable to making a user wait for external calls.

13. Retryable vs Non-Retryable Errors

Category	Example	Approach
Transient	429, 502, 503	Retry with delay/backoff and logging.
Timeout	504	Reduce/split workload and retry only when appropriate.
Authentication	401	Fix token/credentials; do not blindly retry.
Permission	403	Fix permissions or configuration.
Bad request	400	Fix request payload, endpoint or query.

14. Production Retry Checklist

Detect the HTTP status code.
Check Retry-After when supplied.
Classify the error as transient or permanent.
Apply a cool-off period.
Use exponential backoff when appropriate.
Add jitter for high-concurrency workers.
Set a maximum retry count.
Log each retry with useful context.
Move unrecoverable work to a failure/dead-letter process.
Measure retry rate and total processing time.

15. Common Mistakes

Retrying every error

Authentication and validation errors normally require a configuration or payload fix, not repeated retries.

Ignoring Retry-After

If the service tells you how long to wait, your client should respect that guidance.

Using unlimited retries

An integration that retries forever can become a hidden resource consumer and may never recover from permanent failures.

Too much parallelism

High concurrency can create request spikes and increase throttling. Control worker count and measure throughput.

Polling too frequently

Repeatedly scanning collections is often less efficient than using change notifications where supported.

16. Monitoring and Telemetry

For production integrations, track HTTP status codes, latency, retry counts, failure reasons and throughput. Business Central web service telemetry exposes dimensions such as HTTP status code and failure reason that can help troubleshoot unsuccessful calls.

17. Recommended Architecture

A reliable Business Central integration combines several techniques rather than relying on one trick:

Efficient API endpoint design
Filtering and pagination
Controlled concurrency
Webhook/change notification where possible
Retry-After support
Exponential backoff
Queue-based processing
Structured logging and monitoring

FAQ

What does HTTP 429 mean in Business Central?

It means the API request limits have been exceeded and the client is being throttled.

Should I retry a 429?

Yes, when the operation is retryable. Wait for the recommended delay, use backoff, and stop after a sensible retry limit.

How can I avoid throttling?

Reduce unnecessary calls, filter data, paginate correctly, control concurrency, avoid aggressive polling and use batching or webhooks where appropriate.

Does Business Central have a fixed universal rate-limit number?

Do not hard-code a universal request-per-second assumption into an integration. Business Central has operational limits and throttling behavior, and Microsoft documents that limits can change. Design clients to handle the documented status codes and retry behavior instead.