Adal Destinations

What is a Destination?

A Destination tells Adal where to deliver requests received by a Server.

The Server receives and stores incoming webhooks; the Destination defines where those webhooks go next:

A Server can have multiple Destinations. Adal sends the request to each one and tracks every delivery independently. A request can therefore reach one Destination successfully even if another is temporarily unavailable or returns an error.

A Destination can be a local application connected through Adal CLI or a public HTTP URL. If a Server has no Destinations, Adal will continue to receive and store requests but will not forward them automatically.

Delivery methods

When you create a Destination, choose how Adal should deliver requests to its URL: directly over HTTP or through Adal CLI.

Direct HTTP

Adal sends requests directly to a public HTTP or HTTPS URL. The target service must be reachable from the internet and accept incoming connections from the Server's region. This method is best suited to production services, public APIs, and servers with their own HTTPS setup.

Adal CLI

Adal passes the request to a connected CLI, which forwards it to the Destination URL from within your network. Because the CLI opens an outbound connection to Adal, you do not need to expose your local service or open inbound ports.

Use this method for local development, servers behind NAT, and services on private networks.

Important: Both methods define the same final URL; only the route from Adal to the target service is different.

Create a Destination

Open Destinations in the dashboard, select Add Destination, and complete the form.

1. Select a region.

2. Select the Server whose requests you want to deliver.

3. Enter a descriptive name.

4. Choose Direct HTTP or Adal CLI.

5. Enter the target URL.

6. Choose between 1 and 10 delivery attempts.

7. Add an optional note.

8. Select Save Destination.

The Destination is linked to the selected Server when it is created. New requests received by that Server will then be delivered to the URL using the method you chose.

Important: The name and note are for dashboard use only. They are not added to the HTTP request or sent to the target service.

Configure delivery through Adal CLI

Choose Adal CLI when the target runs on your computer, behind NAT, or on a private network and is not reachable directly from the internet.

Destination URL

Enter an address reachable from the machine running the CLI, for example:

The URL does not need to be public. A local or private-network address works as long as the CLI can connect to it.

Connect the CLI

Start the CLI with the token for the Server selected when you created the Destination:

The CLI opens an outbound connection to Adal. After it connects, it receives requests for the Server and forwards them to the Destination URL. Its connection status appears in the dashboard.

When the CLI or local service is unavailable

If the CLI is disconnected, Adal does not begin an attempt or reduce the number remaining. Delivery stays pending until the CLI reconnects.

If the CLI is connected and receives a request but cannot reach the target URL, the attempt fails. Adal records the result and applies the Destination's retry settings.

The Server setting Deliver pending requests on connection controls requests queued while the CLI is offline. When enabled, stored pending requests are delivered after reconnection; when disabled, the CLI receives only new requests.

Important: This pending-request setting belongs to the Server, not to an individual Destination.

Configure Direct HTTP

Choose Direct HTTP when Adal should contact the target service directly, without a CLI.

Destination URL

Enter the public base URL of the target service, for example:

The service must be publicly reachable. HTTPS is recommended for public Destinations, especially when webhooks contain personal data, tokens, or other sensitive information.

Forwarded request

Adal forwards an exact copy of the incoming request URI. The path and query string are not appended to the Destination address as an arbitrary string and are not replaced by values from the Destination settings.

For a Destination URL of https://example.com and an incoming URI of /some/path?some=parameter, the delivery URL is:

Along with the original URI, Adal forwards:

• the HTTP method;

• headers;

• the request body.

The Destination setting therefore supplies the scheme, host, and port of the target service, while the URI is taken from the accepted request without changes.

Check availability

Before saving, make sure the URL accepts the expected HTTP method and does not require local-network access. Use Adal CLI for private services.

If the connection cannot be established or the service returns an error, Adal records a failed attempt and applies the Destination's retry settings.

Important: Direct HTTP does not require Adal CLI. Requests go directly from Adal's infrastructure to the Destination URL.

Linking Destinations to Servers

Each Destination belongs to one Server, which determines the incoming requests it receives. A Server can have several Destinations, subject to your plan limits, and Adal creates a separate delivery for each one.

For example, requests from a payments Server can be sent at the same time to a local application, a production service, and an audit system:

Deliveries run and are tracked independently. A failure on one Destination does not block the others: the same request can succeed in production and fail when sent to the audit system.

With no Destinations configured, the Server still receives and stores requests but does not forward them automatically.

Important: To send a Server's requests to several places, create one Destination for each target service.

How delivery works

Delivery begins after the Server receives and stores a request. Adal then handles every Destination for that Server independently:

1. Find the Server's configured Destinations.

2. Create a separate delivery attempt for each one.

3. Use Direct HTTP or Adal CLI as configured.

4. Send the original method, URI, headers, and body.

5. Record the response or error.

6. If necessary, schedule the next attempt using the Destination's retry policy.

A result belongs to one attempt for one Destination. There is no shared status that forces every route to finish the same way: each route follows its own delivery and retry cycle.

A response confirms that the HTTP request reached the target. It does not prove that the target fully processed the webhook, wrote data, or completed its business operation — that remains the responsibility of the target application.

Delivery results and retries

Successful delivery

Any 2xx response counts as successful, and Adal schedules no further automatic attempts.

A 2xx status confirms that the target received the request. It does not guarantee that the target completed its internal processing successfully.

Failed delivery

An attempt fails when the response is outside the 2xx range or the request cannot be completed. For example:

• a network connection could not be established;

• a timeout expired;

• a DNS or TLS error occurred;

• the Destination returned a 4xx or 5xx status;

• the CLI cannot reach the local service.

A disconnected Adal CLI is not a failed attempt. While the CLI is offline, delivery remains pending and unused attempts are preserved.

Automatic retries

You can configure 1–10 attempts per Destination. The value applies only to that Destination and includes the first delivery attempt. Choosing one means there are no automatic retries.

The first attempt runs without an extra delay. After a failed attempt finishes, Adal calculates the next delay as:

n is the number of the next attempt: attempt 2 runs 4 minutes after the first finishes, attempt 3 runs 9 minutes after the second finishes, attempt 4 runs 16 minutes after the third finishes, and so on.

If the CLI disconnects while an attempt is waiting, that attempt is not consumed. After reconnection it runs immediately if its scheduled time has already passed. The countdown for the next attempt starts only after the current attempt finishes.

For example, after the third attempt Adal CLI is offline for an hour. After reconnection, attempt 4 runs immediately because its 16-minute delay has already passed. If it fails, attempt 5 runs 25 minutes after attempt 4 finishes.

Retries stop after a 2xx response or when all configured attempts have been used. Automatic retries belong to the original request and do not consume extra credits.

Important: Retries are independent for every Destination. Success on one route does not cancel a retry on another.

Delivery history

Delivery history helps you follow an accepted request to each Destination. Open the request in the dashboard to inspect its delivery attempts.

For each attempt, Adal shows technical result details, including:

• the Destination and delivery method;

• the attempt number;

• the date and time;

• the current status;

• the HTTP response status when available;

• the request duration;

• a network, DNS, TLS, or other error message.

Attempts are grouped by Destination. For one incoming request you can therefore see separately that Destination A succeeded, Destination B is waiting for the CLI, and Destination C has an automatic retry scheduled.

A pending status means the attempt has not started. For example, delivery through Adal CLI stays pending while the CLI is disconnected; that record does not use the attempt allowance.

Important: Adal does not store response headers or bodies. History includes the HTTP status, duration, and diagnostic details, but not the full response content.

Attempt history is stored with the request and follows the retention period configured for its Server.

Manual retry, cancellation, and Replay

Manual delivery retry

A manual retry runs delivery of an existing request to one Destination again without affecting other routes.

You can manually retry not only failed or cancelled deliveries, but also successful ones. That can be useful after changing the target service settings or when you need to process the event again.

Each manual retry is a separate operation and costs 1 credit. Automatic retries, by contrast, belong to processing of the original request and do not consume extra credits.

Cancel a pending delivery

You can cancel any pending delivery. After cancellation, Adal does not run the scheduled automatic attempt for that delivery.

Cancellation cannot recall a request that has already been sent and does not affect other Destinations. If you still need to send the request to the cancelled Destination, start the delivery manually.

Replay a request

Replay sends a stored request through the Server process again. Adal creates a new request based on the original and starts normal delivery to every Destination configured for the Server at replay time.

The original request remains unchanged. Unlike a manual retry to one Destination, Replay creates a new request and new deliveries. The operation costs 1 credit.

Idempotency key

An idempotency key helps the target service recognize repeated deliveries of the same request and avoid performing the same business operation more than once.

Enable the header in the Destination settings after the Destination is created. When enabled, Adal adds this header to the delivered request:

The key is created at the request level, not per delivery. The same request therefore gets the same X-Adal-Idempotency value for every Destination that has the setting enabled.

To use the key, the target service must store processed header values and skip the operation when it receives a value it already knows.

Important: An idempotency key does not guarantee exactly-once delivery. Adal may send a request again; the target service is responsible for preventing duplicate processing.

Destination security

A Destination sends stored webhooks to an external or local service. Treat it as access to sensitive data: verify its URL, restrict access to the target application, and keep its configuration private.

Use HTTPS for Direct HTTP

Use HTTPS with a valid TLS certificate for public Destinations to protect the webhook URI, headers, and body in transit from Adal to the target service.

Protect the Adal CLI token

The token links the CLI to the Server. Never put it in source control, application logs, screenshots, or public commands. Run the CLI only in a trusted environment and limit access to the process and its configuration.

The CLI connects securely to Adal over outbound WSS, so you do not need to open an inbound port for Adal to connect. Security between the CLI and the local Destination depends on your network and URL.

Verify webhooks in the target application

Adal delivers the received method, URI, headers, and body, but does not replace authentication in your application. If the sender signs webhooks, verify the signature before processing the event and reject requests with an invalid signature.

Use X-Adal-Idempotency when the Destination has the header enabled, so a repeated delivery does not repeat a sensitive operation.

Configuration and data storage

Adal encrypts Destination configuration and stored webhook data. URI, header, and body values are not copied into Adal logs, traces, metrics, or monitoring messages.

Request data and delivery history are deleted according to the Server's retention period. Adal does not store response headers or bodies returned by the Destination.

Important: You are responsible for securing the target URL and for handling the data safely after delivery.

Limits and behavior

Delivery timeouts

Adal allows up to 5 seconds to connect to a Destination. The full timeout for one attempt, including connection, transfer, and response, is 30 seconds.

If either timeout expires, the attempt fails and follows the normal automatic retry process.

Direct HTTP addresses

Direct HTTP supports HTTP and HTTPS URLs, including non-standard ports and redirects. For HTTPS, the minimum supported protocol version is TLS 1.2.

Local addresses are not allowed for Direct HTTP. This restriction prevents the Adal Server from sending requests to itself. For delivery to localhost, loopback addresses, or services on a private network, use Adal CLI.

Plan and retention limits

The maximum number of Destinations per Server and the allowed incoming request size depend on your plan. Each Destination supports 1–10 delivery attempts.

Attempt history remains with the request until the Server's retention period expires. Response headers and bodies from the Destination are not stored.

Delete a Destination

Deleting a Destination permanently removes its configuration and related data, including pending deliveries and attempt history. Scheduled attempts are no longer run.

The incoming request and deliveries to other Destinations remain intact because they belong to the Server and are tracked independently.

Important: Deletion cannot be undone. To stop a pending delivery temporarily, cancel it instead of deleting the Destination.

Troubleshooting

The request was received but not delivered

Open the request in the dashboard and inspect the Destination's delivery history. Verify that the Destination belongs to the correct Server and that its URL and delivery method are correct.

If there are no attempts, delivery may be waiting for Adal CLI. If an attempt already ran, check its HTTP status or error message.

Adal CLI appears disconnected

Make sure it is running with the correct Server token and can open outbound WSS connections. Check the internet connection, firewall, proxy, and CLI logs.

While the CLI is disconnected, delivery stays pending and does not consume attempts. After reconnection, an attempt that is already due runs immediately.

The CLI cannot reach the local service

Confirm that the service is running and reachable from the same machine as the CLI, and verify the URL scheme, host, and port.

The Destination returns 404

Adal forwards an exact copy of the incoming URI. If the Server received /some/path?some=parameter, the target must handle that same path and query string. Check the application routes and do not add the path to the Destination's base URL.

The Destination returns 401 or 403

The target service rejected the request at the authentication or authorization layer. Check the headers, tokens, webhook signature, and permissions it expects.

The Destination returns 429 or 5xx

This is a failed attempt. Adal retries on schedule until it receives 2xx or exhausts the configured attempts. Check the target's rate limits and logs.

Connection, DNS, TLS, or timeout errors

• Check public DNS and host availability.

• Make sure the port is open and the service accepts connections.

• For HTTPS, verify the certificate and TLS 1.2+ support.

• Keep within the 5-second connection and 30-second attempt limits.

• Use Adal CLI for local addresses instead of Direct HTTP.

The same request arrived more than once

A repeat can follow an error, timeout, or lost response: the target may have processed the request even if Adal did not receive a successful status. Enable X-Adal-Idempotency and deduplicate by that header value in the target application.

One Destination succeeded and another failed

This is expected because deliveries are independent. Inspect the failing Destination's URL, status, errors, and remaining attempts separately from the successful route.

Important: After fixing the cause, manually retry that delivery. Use Replay only when you need a new request delivered to all current Destinations.

Related pages

• Quickstart — create a Server and Destination, then make your first test delivery.

• Servers — request intake, regions, limits, and Server settings.

• Data storage and retention — what request and delivery data Adal stores and when it is deleted.

• Security — encryption, data access, and guidance for protecting your configuration.

• Why webhooks need idempotent processing — why duplicate deliveries happen and how to use X-Adal-Idempotency.