When you call an external API from Business Central using HttpClient , the happy path is easy. The hard part starts when the API returns 429 Too Many Requests or 503 Service Unavailable . A single failed call can break a posting routine, leave a sales order half-synced, or throw a raw error at the user. This post shows a clean, production-ready retry pattern in AL with exponential backoff. Why You Need Retry Logic Most modern APIs (payment gateways, WhatsApp Cloud API, shipping providers, Azure services) enforce rate limits. When you exceed them, the server responds with HTTP 429 and often a Retry-After header. Transient failures like 503 and 504 are also common under load. Without retry logic, your integration is only as reliable as the busiest second on the remote server. The Core Pattern The idea is simple: wrap the send call in a loop, catch retryable status codes, wait a growing interval between attempts, and give up after a maximum number of tries. codeunit 50120 ...

Sooner or later every Business Central developer needs to expose data to the outside world — a website, a Power Automate flow, a mobile app, or another system. The modern way to do this is with a custom API page in AL. Unlike the older "publish as web service" approach, an API page gives you a clean, versioned, high-performance REST endpoint that follows Microsoft's OData v4 conventions. Note: If want to Check Standard API then visit Standard API List   In this tutorial we will build a simple Customer Rating API from scratch, publish it, and call it. You only need VS Code with the AL extension and a Business Central sandbox. Step 1: The table we will expose We will use a small custom table so the example is self-contained. table 50100 "Customer Rating" { DataClassification = CustomerContent; fields { field(1; "No."; Code[20]) { } field(2; "Customer No."; Code[20]) { TableRelation = Cus...

Every AL developer meets the same handful of compiler errors over and over — usually the moment they hit F5 and the build fails. This post collects the ten you are most likely to see in Visual Studio Code when building Business Central extensions, explains what each one actually means, and shows the fix with a short example. Tip: in VS Code, the error code (like AL0432 ) appears in the Problems panel. Searching that exact code is the fastest way to a fix — so each error below is labelled with its code. 1. AL0185 — The name does not exist in the current context The compiler cannot find a variable, method, or object with that name. Almost always a typo, a missing var declaration, or a dependency you forgot to add to app.json . // Error: 'Custmer' does not exist in the current context Custmer.FindFirst(); // typo // Fix: declare it and spell it correctly var Customer: Record Customer; begin Customer.FindFirst(); end; 2. AL0432 — This method is only support...

If you learned C/AL in the Dynamics NAV era, the good news is that most of your knowledge still applies. AL , the language of Microsoft Dynamics 365 Business Central, kept the core concepts — tables, pages, codeunits, triggers but modernized the syntax and moved everything to an extension-based model. C/AL and the classic C/SIDE environment were retired back in Business Central version 15 (2019), and as of 2026 we are already 13 major versions into the fully AL-based world. This cheat sheet maps the most common C/AL patterns to their AL equivalents so you can migrate old code (or old skills) quickly. 1. The big picture: what changed Concept C/AL (NAV) AL (Business Central) Development tool C/SIDE (Object Designer) Visual Studio Code + AL Language extension Customization model Modify base objects directly Extensions only never modify the base app Object files Stored in the database Plain-text .al files in a project, version-controlled with Git Deployment Import .fob / .txt ...