This page describes how to deploy and configure the App and API Protection callout service for Azure API Management (APIM) without using the one-click template. If you have not deployed the integration yet, start with Enabling App and API Protection for Azure API Management.

The callout service ships as the container image ghcr.io/datadog/dd-trace-go/apim-callout:latest. It listens on two ports:

• 8080 serves the callout endpoint, POST /, which handles all request and response phases.
• 8081 serves the health endpoint, GET /.

Deployment options

DD_API_KEY=<your-datadog-api-key> \
  ./deploy/azure/deploy.sh \
  --resource-group <rg-name> \
  --apim-name <apim-service-name>

module apimCallout 'path/to/contrib/azure/apim-callout/deploy/azure/main.bicep' = {
  name: 'dd-apim-callout'
  params: {
    datadogApiKey: keyVault.getSecret('dd-api-key')
    apimServiceName: 'my-apim'
    logAnalyticsWorkspaceId: logAnalytics.id
    // every other parameter has a default
  }
}

docker run -d \
  -p 8080:8080 \
  -p 8081:8081 \
  -e DD_AGENT_HOST=datadog-agent \
  ghcr.io/datadog/dd-trace-go/apim-callout:latest

curl -s http://localhost:8081/
# {"status":"ok","library":{"language":"golang","version":"2.x.x"}}

Networking

Address ranges

vnetAddressPrefix and --vnet-address-prefix set the address space of the virtual network, but the subnet prefixes inside it are fixed:

Because the deployment does not derive the subnets from the address space, any value you set must contain these three prefixes. The default 10.0.0.0/16 does. A value such as 10.1.0.0/16 leaves the subnets outside the virtual network, and the deployment fails.

To place the callout service in a different address range, supply your own network with existingVnetId instead.

Using an existing virtual network

Setting existingVnetId makes the deployment skip the virtual network, subnets, network security groups, and NAT gateway. You supply those instead, so existingAcaSubnetId and existingAciSubnetId become required, and each subnet must meet the requirements the deployment would otherwise have set up:

• The callout subnet needs a Microsoft.App/environments delegation, and enough addresses for the Container Apps environment.
• The Agent subnet needs a Microsoft.ContainerInstance/containerGroups delegation, and outbound connectivity so the Agent can reach Datadog.
• The callout service must reach the Agent on port 8126.

The deployment also creates no APIM subnet in this mode, so the APIM instance must already be integrated with the same virtual network. Otherwise the APIM configuration step can fail, or APIM cannot resolve the callout service.

Configuration

The callout service enables the Datadog Web Application Firewall (WAF) itself at startup, so you do not need to set DD_APPSEC_ENABLED.

The service supports the following settings:

Automatic defaults

If the following variables are unset, the service assigns them at startup:

If a single WAF evaluation exceeds its budget, the request is allowed rather than delayed.

Datadog Agent connection

The callout service does not send data directly to Datadog. It sends traces and security events to a Datadog Agent, which forwards them to Datadog. The callout service and Agent run in separate containers, and each has its own environment variables.

On the callout container:

On the Datadog Agent container:

Because the callout runs in its own container, DD_APM_ENABLED and DD_APM_NON_LOCAL_TRAFFIC are both required. Without them the Agent drops the spans and security events this integration produces. The one-click deployment sets all of these on the Agent container for you.

Do not set DD_API_KEY on the callout container. The one-click deployment sets DD_AGENT_HOST on the callout container and maps datadogApiKey and datadogSite to DD_API_KEY and DD_SITE on the Agent container.

Your site is .

Encrypting the callout endpoint

To serve the callout endpoint over HTTPS, set DD_APIM_CALLOUT_TLS to true and provide both DD_APIM_CALLOUT_TLS_CERT_FILE and DD_APIM_CALLOUT_TLS_KEY_FILE. If TLS is enabled and either file is missing, the service does not start. The minimum accepted TLS version is 1.2.

When TLS is enabled, the APIM policy must call the service over https://.

Health check

Check the health endpoint on port 8081:

curl -s http://localhost:8081/
# {"status":"ok","library":{"language":"golang","version":"2.x.x"}}

A 200 response indicates that the service is running, but does not indicate the state of the WAF. To confirm that security data is arriving, use the Datadog UI checks described in Enabling App and API Protection for Azure API Management.

Sizing and performance

On a 0.5 vCPU, 1 GiB Azure Container Apps deployment, the request-headers and response-headers phases each take about 2.4 ms. The full APIM pipeline, including both callouts and the backend, takes about 9.7 ms.

Body phases run only when body inspection is enabled and the previous phase requested the body. The gateway maintains a connection pool to the callout service, which can reduce latency in production.

To minimize network round-trip time, deploy the callout service in the same Azure region as your APIM instance, and keep APIM close to your API consumers. By default, the service scales from 1 to 10 replicas and scales out at 20 concurrent requests per replica.

Further reading

Additional helpful documentation, links, and articles:

Enabling App and API Protection for Azure API ManagementDOCUMENTATION Azure API Management policies for App and API ProtectionDOCUMENTATION App and API Protection Azure API Management callout source codeSOURCE CODE Troubleshooting App and API ProtectionDOCUMENTATION