Core Adal concepts

Two delivery flows

Adal receives incoming webhooks and executes outgoing HTTP requests. Both flows provide a journal and attempt results, and consume the same account traffic balance.

• Inbound: an external sender calls your Server's public URL. Adal receives the request and delivers it to connected recipients.

• Outbound: your application submits an HTTP job through the API using an API token. No incoming Server is required.

How the entities connect

The Inbound diagram shows configuration relationships. A Router selects Channels; it does not transform HTTP content. Each recipient has independent delivery progress.

Server

A Server provides a public, regional webhook ingest URL and defines intake and sender-response settings. The region and address are selected at creation and cannot subsequently change. See Servers.

Request

In Inbound, a Request records an accepted or rejected call. Accepted requests expose HTTP data while available, along with delivery history. Rejected requests are not executed at recipients. An Outbound submission has its own identifier and journal; API acceptance does not mean that the HTTP call has executed.

Channel, Endpoint and Router

A Channel groups Endpoints and selects delivery through Direct, which delivers to a hosted recipient, or CLI, which delivers through Adal CLI on your computer. An Endpoint defines one recipient URL and its delivery settings. A Router links one or more Servers to one or more Channels.

A recipient is not a separate setting owned exclusively by one Server. A Channel can participate in multiple connections. See Channels and Endpoints.

Delivery and attempt

A delivery is the work of forwarding a request to a recipient. An attempt is one HTTP call within that work. In Inbound, the aggregate status covers all recipients: one recipient succeeding does not mean the others succeeded. A request without recipients can remain received.

In Outbound, API response 202 confirms job acceptance, not recipient success. HTTP success means the recipient returned a successful response under the execution rules; it does not prove that a business operation completed in another system.

Retry and resubmission

An automatic retry continues an existing delivery after an unsuccessful attempt. Another API call from your application is a new submission operation; use an idempotency key to protect against a duplicate job when needed.

The current dashboard does not provide a separate manual replay or delivery restart action. Do not confuse automatic attempts with creating a new request. See Retries and idempotency.

Region and retention

The region determines where HTTP data is executed and stored. Content availability is time limited; history and minimal metadata can remain after bodies are removed. Selecting a region does not imply automatic migration or failover to another region. See Regions and Storage.

Security and responsibility

Verify sender signatures, validate input and protect handlers against repeated side effects. Keep API, CLI and provider secrets out of URLs, screenshots and ordinary logs. Adal does not replace sender authentication or your application's business checks.

When to use Adal

Receive webhooks at a stable URL, deliver to a local application through CLI, forward an event to multiple applications, run outgoing HTTP jobs with automatic attempts, and investigate failed deliveries.

Boundaries

The service does not replace permanent archives, your database, application transactions or backups. Do not rely on exactly-once external effects, strict global ordering, fixed latency or guaranteed availability.

Glossary

Start here

• Inbound quickstart.

• Outbound quickstart.

• Account and API tokens.

• Traffic and balance.