Are your web service calls getting blocked by the environment?

Using outgoing web service calls can be blocked. Check this video to figure out how to handle this gracefully:

https://youtu.be/It6AtUSB8gE

Have you ever had a web service call in your AL extension that mysteriously fails with no clear explanation? You deploy your app, everything looks correct in your code, but the HTTP call just… doesn’t work. In this video, Erik walks through a common but often overlooked cause: the environment itself is blocking your outbound HTTP requests. He shows how to detect this situation in code and provide users with a helpful error message instead of leaving them confused.

The Problem: Web Service Calls That Silently Fail

Erik demonstrates this using an app that calls an external web service to retrieve the IP address of the calling machine. When he triggers the call, it simply doesn’t work — no IP address is returned, and there’s no obvious error.

Stepping through the code with the debugger reveals that the HttpClient.Get() method returns false. The code never even gets to check the HTTP status code because the call itself is being blocked before it can reach the external service.

The Root Cause: “Allow HttpClient Requests” in Extension Management

The explanation lies in Extension Management. The first time any extension attempts to make an outbound HTTP call, Business Central prompts the user with a security dialog asking whether to allow or block the connection. If a security-conscious user chooses to block the request, a flag on the extension is turned off — and from that point on, all outbound HTTP calls from that extension will silently fail.

You can find this setting by navigating to Extension Management, selecting the extension, and looking at its configuration page. There’s a toggle called “Allow HttpClient Requests”. When it’s off, your web service calls are dead in the water. Turning it back on immediately restores functionality.

What makes this particularly tricky is that Erik has observed this flag getting turned off unexpectedly — possibly after upgrades or other environment changes — even for users who had previously allowed the requests. The exact reason isn’t always clear, but it happens often enough to be a real concern in production environments.

The Solution: Check IsBlockedByEnvironment

Even when HttpClient.Get() (or Send()) returns false, the HttpResponseMessage object still contains useful information. Specifically, you can call Response.IsBlockedByEnvironment to determine whether the failure was caused by the environment blocking the request rather than a network error or a bad endpoint.

Here’s how you might structure this check in your code:

if not Client.Get('https://api.example.com/endpoint', Response) then begin
    if Response.IsBlockedByEnvironment() then
        Error('Please turn on "Allow HttpClient Requests" from the app''s configure page in Extension Management to allow this app to make web service calls.')
    else
        Error(GetLastErrorText());
end;

This pattern gives users a clear, actionable message telling them exactly what they need to do, rather than leaving them staring at a cryptic error or — worse — no error at all.

The Source Code: A Complete Example

The source code provided with the video demonstrates an extension that adds HTTP functionality to the Customer List page. While the specific example focuses on sending a POST request, the same principle applies to any outbound HTTP call:

namespace DefaultPublisher.HttpClientProblem;

using Microsoft.Sales.Customer;
using System.Utilities;

pageextension 50100 CustomerListExt extends "Customer List"
{
    trigger OnOpenPage();
    var
        Client: HttpClient;
        Request: HttpRequestMessage;
        Response: HttpResponseMessage;
        Content: HttpContent;
        Headers: HttpHeaders;
        Data: Text;
    begin
        message('%1', format(false));
        Request.SetRequestUri('https://microsoft.com');
        Request.Method := 'POST';

        Data := '❤️';

        Content.WriteFrom(Data);
        Content.GetHeaders(Headers);
        Headers.Add('Content-Length', format(StrlenUTF8(Data)));
        message('strlen=%1 vs utf8=%2', strlen(Data), StrlenUTF8(Data));

        Request.Content := Content;

        if Client.Send(Request, Response) then
            message('You should not see the message, then Erik messed up!?')
        else
            error(GetLastErrorText());
    end;

    procedure StrlenUTF8(S: Text): Integer
    var
        TmpBlob: Codeunit "Temp Blob";
        OutS: OutStream;
    begin
        TmpBlob.CreateOutStream(OutS, TextEncoding::UTF8);
        OutS.WriteText(S);
        exit(TmpBlob.Length());
    end;
}

Notice that the else branch currently calls error(GetLastErrorText()). To make this more robust, you’d add the IsBlockedByEnvironment check before falling through to the generic error, exactly as Erik described.

Best Practice: Always Check for This

Erik’s strong recommendation — and what he now does in all of his apps — is to always check for IsBlockedByEnvironment whenever you make a web service call. This is especially important when:

  • Your HTTP call is buried deep in the call stack, several layers removed from the user interaction
  • You have multiple extensions that rely on outbound web services
  • Your app is deployed to customer environments where you don’t control the initial setup
  • Environment upgrades or changes may reset the permission flag

At eFocus, where they have several apps that rely heavily on web services, Erik has seen this issue occur repeatedly. Building in the IsBlockedByEnvironment check means users always get a clear, friendly explanation and know exactly which switch to flip to restore functionality.

Conclusion

If your web service calls in Business Central are failing mysteriously, the “Allow HttpClient Requests” flag in Extension Management might be the culprit. It’s a security feature that can be inadvertently triggered by users or unexpectedly reset during upgrades. By checking Response.IsBlockedByEnvironment in your code, you can detect this situation and guide users to the fix — making your extensions more robust, predictable, and user-friendly. It’s a small addition to your code that can save significant troubleshooting time.

Picture of hougaard

hougaard