How can developers securely consume external web services from AL while handling authentication failures and API timeouts?
Question
Developers need to understand HTTP methods, headers, authentication, JSON handling, status codes, timeouts and secure credential management.
A production integration should also handle authentication failures, transient errors and unexpected API responses without disrupting business processes.
The discussion can explore when synchronous API calls are appropriate and when asynchronous integration patterns should be considered.
Discussion: How would you design an AL integration that remains reliable when the external API is temporarily unavailable?
Answers
External API integration from Business Central should be designed as an integration boundary, not simply as an HttpClient call. Authentication, HTTPS, permissions, timeout behaviour, response validation, error handling and operational monitoring all need to be considered. Microsoft documents OAuth and service-to-service authentication options for Business Central web-service scenarios and provides security guidance for web-service integrations.
A conceptual design is:
Business Central | v Integration Code | +---- Authentication | +---- HTTPS | +---- Request | v External API | +---- Success | +---- Authentication Failure | +---- Timeout | +---- Other HTTP Error
Authentication should use an appropriate supported mechanism rather than embedding credentials or secrets directly in AL source code. For service-to-service integrations, the identity should be granted only the permissions required by the external API.
Developers also need to distinguish different failure categories.
Authentication failure may indicate an expired token, incorrect credentials, incorrect scope, certificate issue or configuration problem. Repeatedly retrying an authentication failure is usually not an appropriate solution; the underlying authentication configuration needs investigation.
Timeout or transient connectivity failure is different. Depending on the API and business process, a transient failure may be eligible for controlled retry. The retry strategy should use bounded attempts and appropriate backoff rather than immediately sending repeated requests.
Business/API validation failure should generally not be treated as a transient infrastructure problem. For example, a 400 response caused by invalid business data requires correction rather than repeated retries.
A robust pattern is:
API Request | v Authenticate | v Send Request | +---------- Success ----------> Process Response | +---------- Auth Error -------> Configuration / Token Investigation | +---------- Timeout ----------> Controlled Retry if Appropriate | +---------- Validation Error -> Business Error Handling | +---------- Other Failure ----> Log + Investigate
For professionals, also consider logging without exposing secrets or sensitive payloads, correlation identifiers, monitoring, idempotency and what happens when Business Central is temporarily unable to reach the external service.
For interview preparation, avoid answering simply "Use OAuth." A stronger answer explains how the identity is established, where credentials are managed, how failures are classified, when retries are appropriate, and how the integration is monitored.