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.
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.
- Select a region.
- Select the Server whose requests you want to deliver.
- Enter a descriptive name.
- Choose Direct HTTP or Adal CLI.
- Enter the target URL.
- Choose between 1 and 10 delivery attempts.
- Add an optional note.
- 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.
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.
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, 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 receives a request but cannot reach the target URL, the attempt fails and the Destination's retry policy applies.
The Server setting Deliver pending requests on connection controls requests queued while the CLI is offline. When enabled, they are delivered after reconnection; when disabled, the CLI receives only new requests.
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, especially when webhooks contain personal data, tokens, or other sensitive information.
Forwarded request
Adal preserves the incoming request URI. For a Destination URL of https://example.com and an incoming URI of /some/path?some=parameter , the delivery URL is:
Adal also forwards the original HTTP method, headers, and body. The Destination setting supplies the scheme, host, and port; the incoming URI remains unchanged.
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. Connection failures and error responses are recorded as failed attempts and follow the Destination's retry policy.
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.
├── Adal CLI → local application
├── Direct HTTP → production service
└── Direct HTTP → audit system
Deliveries are independent: a failure on one route does not block the others. With no Destinations configured, the Server still receives and stores requests but does not forward them automatically.
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 independently:
- Find the Server's configured Destinations.
- Create a separate delivery attempt for each one.
- Use Direct HTTP or Adal CLI as configured.
- Send the original method, URI, headers, and body.
- Record the response or error.
- 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.
A response confirms that the HTTP request reached the target. It does not prove that the target fully processed the webhook or completed its business operation.
Delivery results and retries
Successful delivery
Any 2xx response counts as successful, and Adal schedules no further automatic attempts. It confirms receipt, not successful internal processing by the target.
Failed delivery
An attempt fails when the response is outside the 2xx range or the request cannot be completed—for example because of a connection, timeout, DNS, or TLS error; a 4xx or 5xx response; or a CLI that cannot reach the local service.
A disconnected CLI is not a failed attempt. Delivery remains pending and its unused attempts are preserved.
Automatic retries
You can configure 1–10 attempts per Destination, including the first attempt. Choosing one means there are no automatic retries. After a failed attempt, Adal calculates the next delay as:
n is the number of the next attempt: attempt 2 runs after 4 minutes, attempt 3 after 9 minutes, attempt 4 after 16 minutes, and so on. Each delay starts when the previous attempt finishes.
If the CLI disconnects while an attempt is waiting, that attempt is not consumed. It runs immediately after reconnection if its scheduled time has passed.
Retries stop after a 2xx response or when all configured attempts have been used. Automatic retries do not consume extra credits.
Retries are independent for every Destination. Success on one route does not cancel a retry on another.
Delivery history
Open a request in the dashboard to inspect its deliveries. For each attempt, Adal shows the Destination and method, attempt number, date and time, current status, HTTP response status when available, duration, and any network, DNS, TLS, or other error.
Attempts are grouped by Destination, making it easy to see that one route succeeded while another is waiting for the CLI or has a retry scheduled. A pending attempt has not started and does not use the attempt allowance.
Adal does not store response headers or bodies. History includes the HTTP status, duration, and diagnostic details only.
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 retry failed, cancelled, or successful deliveries. Each manual retry costs 1 credit; automatic retries cost no additional credits.
Cancel a pending delivery
You can cancel any pending delivery. This prevents its scheduled automatic attempt but cannot recall a request already sent and does not affect other Destinations.
Replay a request
Replay sends a stored request through the Server process again. Adal creates a new request and delivers it to every Destination configured for the Server at replay time.
The original request remains unchanged. Replay costs 1 credit.
| Action | What runs again | Credits |
|---|---|---|
| Automatic retry | Delivery to one Destination | No additional credits |
| Manual retry | Delivery to one Destination | 1 credit |
| Replay | Entire request to current Destinations | 1 credit |
Idempotency key
An idempotency key helps the target recognize repeated deliveries of the same request and avoid performing the same operation more than once. Enable it separately for each Destination. Adal then adds:
The key belongs to the request, not the delivery. The first delivery creates a new key; deliveries to other Destinations, automatic retries, and manual retries reuse it. Replay creates a new request with a new key.
Your target service must store processed key values and skip the operation when it sees a value it already knows.
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
Treat a Destination 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.
Protect the Adal CLI token
Never put the Server token in source control, application logs, screenshots, or public commands. Run the CLI only in a trusted environment. The CLI connects securely to Adal over outbound WSS; security between the CLI and the local Destination depends on your network and URL.
Verify webhooks in the target application
Adal forwards the received request but does not replace authentication in your application. Verify the sender's webhook signature before processing an event, and use X-Adal-Idempotency to prevent repeated sensitive operations.
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 follow the Server's retention period; response headers and bodies are not stored.
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 and 30 seconds for the entire attempt, including connection, transfer, and response. A timeout is a failed attempt and follows the normal retry process.
Direct HTTP addresses
Direct HTTP supports HTTP and HTTPS URLs, non-standard ports, and redirects. HTTPS requires TLS 1.2 or later. Local, loopback, and private-network addresses are not allowed; use Adal CLI for them.
Plan and retention limits
The maximum number of Destinations per Server and the 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.
Delete a Destination
Deleting a Destination permanently removes its configuration and related data, including pending deliveries and attempt history. The incoming request and deliveries to other Destinations remain intact.
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 the Server, URL, and delivery method. If there are no attempts, delivery may be waiting for Adal CLI; otherwise, check the HTTP status or error.
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. Pending delivery does not consume attempts and runs immediately after reconnection if already due.
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 preserves the incoming URI. If the Server received /some/path?some=parameter , the target must handle that same path and query string. Do not add the path to the Destination's base URL.
The Destination returns 401 or 403
Check the headers, tokens, webhook signature, and permissions expected by the target service.
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.
- 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.
The same request arrived more than once
A target may process a request even when Adal loses its response or sees a timeout. Enable X-Adal-Idempotency and deduplicate requests by that header 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.
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.