Sending an HTTP request is only the beginning. You still need to know whether the delivery service accepted it, whether the recipient responded, and whether another attempt is on the way. Send the same webhook to several applications, and each recipient may have a different outcome.
Our November 3 update makes that journey easier to follow. We've updated Outbound and incoming webhook delivery, added dashboard summaries and API token management, and replaced subscriptions with one-time traffic purchases. We've also brought the current storage rules together in the documentation.
The goal is practical: give you the information to investigate delivery problems and make everyday integration work easier to manage.
Outbound: follow a request through to the response
With Adal Outbound, your application submits an HTTP request through the API and chooses the region where it will run. You provide the recipient URL, method, headers, and body; Adal Cloud handles execution. There's no need to create an incoming Server or configure a webhook route for an independent outgoing request.
The updated Outbound view gives you more to work with after submission. Each request has an attempt history with HTTP status codes, errors, and connection details. You can investigate whether a problem occurred while establishing the connection, negotiating TLS, or receiving the HTTP response. This information is available in the dashboard and through the API. See the Outbound API guide and delivery diagnostics.
Suppose your application sends a notification and the first attempt fails. The history lets you inspect that failure and follow subsequent attempts. You have a clearer basis for deciding whether to fix the recipient's URL or access settings, or wait for an automatic retry.
You can also save response bodies. Set save_response_body when submitting a request, then download the saved response for a particular attempt separately from the original request body. That can be useful when the recipient returns an error with details in its response.
Response storage is off by default. A response that wasn't saved cannot be recovered by enabling the option later. Saved responses can also be truncated or come from an incomplete read, so check their completeness indicators before treating a downloaded file as the full response. The HTTP data guide covers these details.
As before, a 202 from the Adal Cloud API confirms that the job was accepted. Check the request and its attempts for the delivery outcome. Even a successful HTTP response from the recipient doesn't, by itself, prove that its application completed the business operation.
Incoming webhooks: see each recipient's outcome
We've updated both the configuration and the history for incoming webhook delivery. A Server in Adal Cloud receives webhooks at a public URL. A Channel groups Endpoints, each defining a recipient URL, and a Router connects Servers to Channels. The same Channel can receive requests from several Servers.
Use a Direct Channel for an HTTP recipient reachable from the region. Use a CLI Channel for an application reachable from the computer running Adal CLI. The Channels and Endpoints guide and Router documentation explain the setup.
Each recipient has its own attempts and delivery progress. If one handler accepts a webhook while another is temporarily unavailable, the first handler's success doesn't end delivery to the second. Open the relevant Channel in the request's history to inspect individual Endpoints, their URLs, and their attempts.
This is particularly useful when delivery is only partially successful. A webhook might reach an accounting application while all attempts to reach a second handler fail. The overall partial status captures those different final outcomes; the details show which recipient needs attention. One successful HTTP response doesn't tell the whole story. See the Inbound request history guide for the available states.
We've also improved how Adal CLI resumes unfinished deliveries after reconnecting or restarting. Keep the client's local data so it can continue work it has already saved. The Deliver backlog setting separately controls delivery of requests received while the client was absent. Reconnecting doesn't automatically deliver the Server's entire history. The Adal CLI guide explains the distinction.
An interrupted delivery can still result in a repeated HTTP call. Handlers need idempotent processing so that receiving the same event again doesn't repeat the business operation.
A clearer starting point in the dashboard
The dashboard home page now has separate Inbound and Outbound summaries. They show activity, recent requests, errors, and unfinished deliveries, with links into the request journals when you need to investigate.
Updated filters help you narrow the search by period, status, and region. Journals and request details show where a request was received or executed, along with its traffic usage. The release also includes updates to our regions in Stockholm, Nuremberg, and Almaty. You can see which region handled a request as you investigate its delivery.
You can now create API tokens in the dashboard, choose their expiry dates, check when they were last used, and revoke tokens you no longer need. Each secret is shown only when issued. Your application uses an API token for Outbound calls; CLI Channels have separate connection secrets. See account access and API tokens.
Buy traffic when you need it
We've replaced subscriptions with one-time traffic packages. Purchases add together, paid traffic doesn't expire, and taxes are included in the package price. If your integrations have uneven workloads, you can use the volume you've purchased as requests arrive.
Inbound and Outbound share one account traffic balance. Billing shows the Free and paid balances separately, along with the next Free renewal date and the status of your purchases.
After email verification, you receive 10 MiB of Free traffic, renewed every 30 days without rollover. Renewal resets the Free balance to 10 MiB; it doesn't add another 10 MiB to whatever remains. Your paid balance is preserved. Free traffic is used first, followed by paid traffic. Current packages are available in Billing.
Usage depends on the direction. For Inbound, the accepted request's path, query string, headers, and body count toward traffic. Delivering it to multiple recipients or retrying delivery doesn't multiply that original charge.
For Outbound, the decoded request body is counted once, when the first HTTP attempt begins. If response storage is enabled, the saved response bytes from each attempt count too, including unsuccessful or incomplete responses. For example, a 1,000-byte request body with saved responses of 200 and 300 bytes uses 1,500 bytes. The second attempt doesn't count the original 1,000 bytes again.
The traffic and billing guide has the full accounting rules.
HTTP content is available for 90 days
Incoming and outgoing HTTP content has a 90-day retention period from acceptance, regardless of which traffic package you buy. Retries, reads, purchases, and Free renewals don't extend that deadline.
Request content and delivery history have different lifecycles. After HTTP content is removed, a journal entry may still show the request's status and delivery history. Seeing the entry doesn't mean its body is still available to download.
For Outbound, the same deadline applies to saved response bodies and detailed HTTP diagnostics. Check the deletion date on the individual request. The storage and deletion guide explains what remains available and for how long.
Explore the update
We've updated the documentation alongside our Security page, Privacy Policy, and Terms of Service. They reflect the current Inbound and Outbound features, HTTP data handling, traffic packages, and retention rules.
Open the Adal Cloud dashboard, explore the new summaries, and select a request from a journal. Its details let you follow the delivery outcome, inspect attempts, and see which data is available for investigation. For the full release notes, read the November 3 changelog.