## Two delivery flows {#overview}

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 {#flow}

```text
Inbound:  Sender → Server → Request → Router → Channel → Endpoints
Outbound: Application → API + region → Job → HTTP recipient
```

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

## Server {#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](/en/docs/inbound/servers).

## Request {#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 {#destination}

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](/en/docs/inbound/destinations).

## Delivery and attempt {#delivery}

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 {#retry-and-replay}

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](/en/docs/common/retries).

## Region and retention {#regions-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](/en/docs/common/regions) and [Storage](/en/docs/common/storage).

## Security and responsibility {#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 {#when-to-use}

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 {#when-not-to-use}

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 {#glossary}

| Term | Meaning |
|---|---|
| Inbound | Receive a webhook at a Server and deliver it to recipients |
| Outbound | Submit an independent HTTP job through the API |
| Channel / Endpoint | Delivery mechanism / individual Inbound recipient |
| Router | Connections between Servers and Channels |
| Attempt | One HTTP call to a recipient |
| API token / CLI token | External application API access / CLI connection to a Channel |

## Start here {#related-pages}

- [Inbound quickstart](/en/docs/inbound/quickstart).
- [Outbound quickstart](/en/docs/outbound/quickstart).
- [Account and API tokens](/en/docs/common/account-api-tokens).
- [Traffic and balance](/en/docs/common/traffic).